Quote from: bonenaut7 on May 13, 2024, 02:11:24That's interesting, i was using MemoryStack only in try-with-resources blocks, but in example i provided in #1 post it looks like that's... unnecessary? There is callback when vertex buffer is built, BGFXMemory is no more required to stay and memory could be freed(and it happens exactly when at least a frame with some delay passed), is this callback bad in some way?Allocating native memory (especially in a game loop) is slow (regardless of language). The advantage with the above MemoryStack method is that you just allocate a chunk of memory at initialisation and then reuse it continuously in the game loop.
Quote from: spasi on May 12, 2024, 09:39:10The Java-side buffer object that wraps a native pointer is reclaimed as usual by the GC, when there are no longer any references pointing to it.Oh, got it, thanks!
Quote from: kappa on May 12, 2024, 05:47:35One potential solution for frame data which changes every frame (e.g. immediate mode 2d graphics made up of many small allocations) is to use LWJGL's MemoryStack, just push all your data in there and pop (release) it after 2 frames. e.g. Use 3 MemoryStack's (one for current frame data and two holding data for the previous two frames) and just cycle through the MemoryStack's.
Configuration.DEBUG_MEMORY_ALLOCATOR.set(true);
(or -Dorg.lwjgl.util.DebugAllocator=true
) which enables tracking and memory leak reporting for any native allocation that goes through MemoryUtil's memory allocator (see Configuration.MEMORY_ALLOCATOR
). As I mentioned, this tracking may introduce a lot of overhead, depending on the application (a stacktrace is captured on every allocation, which can optionally be disabled with Configuration.DEBUG_MEMORY_ALLOCATOR_FAST
). But it can accurately report memory leaks and you can also use it to print memory usage statistics at runtime.