BGFX Bindings / How to know is buffer freed or not?

[bonenaut7]

Hello! I'm learning how to use bgfx now and currently stumbled upon vertex buffer creation process.
BGFX has by default some function called  bgfx_make_ref_release  that i can use to get  BGFXMemory  and i have problem with this. When i'm using this method, memory reference should be destroyed after some time (at least a single  BGFX.bgfx_frame  call, and a few milliseconds to process commands), so after waiting, native(i guess) side calls  BGFXReleaseFunctionCallbackI#invoke  method, where i should by logic use something like  MemoryUtil.nmemFree(_ptr) (took this from examples) to free this reference, which points on the  ByteBuffer  and it's  Buffer#address  that i used to create this reference. But there's a thing, i don't know is it freed or not, because  MemoryUtil#nmemFree  nor  MemoryUtil#memFree  are setting anything to a buffer (for example  Buffer#address  field to 0).

How i can find out buffer i'm used to create  BGFXMemory  is freed or not? I'm noticed that even after buffer's memory address being freed, i still can use that buffer and this whole thing kinda scares me

[bonenaut7]

Whole thing looks like this:

short vertexLayout = /* pre-made vertex layout with only 3-unit position attribute */;
ByteBuffer vertexData = MemoryUtil.memAlloc(Float.BYTES * 3);
/* filling vertexData with [1, 2, 3] */
vertexData.flip();

BGFXReleaseFunctionCallbackI callback = (_ptr, _userData) -> {
    System.out.println("callback called");
    MemoryUtil.nmemFree(_ptr);
};
BGFXMemory memoryRef = bgfx_make_ref_release(vertexData, callback, 0);
short vertexBuffer = bgfx_create_vertex_buffer(memoryRef, vertexLayout, BGFX_BUFFER_NONE);

bgfx_frame(false);
Thread.sleep(250L); // Because vertex buffer is not created immidiately at bgfx_frame(...)
// Here we can see on console "callback called" from callback, so MemoryUtil.nmemFree(vertexData.address) is called
// I'm compared what's came to the _ptr in callback as a parameter and which address buffer had, they're was equal

// Here we can do anything with buffer because it's address field is untouched
// But memory is freed and i don't know vertexBuffer will be cleared by GC or not (that's question too)
// And how do i check is it freed or not? except for using Unsafe by myself for checking and setting address to zero

So will be in this situation buffer cleared by GC, and how can i check is it freed or not except for using Unsafe in case if there's any other possibilities?
Will be glad for any help, thanks!

[kappa]

As per the BGFX docs, Data passed (to BGFX) must be available for at least 2 bgfx_frame calls.

So just free memory manually after 2 frame calls of not needing it rather than tracking when BGFX has freed it. This can be a bit cumbersome for data which changes every frame.

One 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.

If you are not familiar with LWJGL's MemoryStack, there is a good write up here on how to use them.

[spasi]

Hey bonenaut7,

There is no easy way to find out whether a pointer has been freed or not. LWJGL does not track this information in its default state (it's too expensive) and indeed nothing happens to buffer wrapper objects when a pointer is freed. Note that this is no different than pure C code, the developer is responsible for tracking pointer lifetimes accurately and avoiding use-after-free bugs. The 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.

LWJGL provides 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.

[bonenaut7]

The 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!
I will try also debugging my app, I didn't knew about debugging features at all

One 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.

That'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?

[kappa]

That'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.

[spasi]

MemoryStack is indeed very useful, but keep in mind that its default size is fairly small and usually not appropriate for vertex/index data (mentioned in the OP).