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
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).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 meQuote from: spasi on May 10, 2024, 12:15:10The log shows that the JVM itself is trying to allocate some memory and fails. Are you maybe running too many programs and the system as a whole runs OOM?Not really many programs, just a few like intellij and a web browser. But yes, the whole system get frozen. It ate up all mermory.
In any case, this doesn't look like an issue with LWJGL.
Quote from: spasi on May 10, 2024, 09:48:53Btw, do you mean a java.lang.OutOfMemoryError or a process-OOM error followed by a JVM crash?
Quote from: fireinwinterfell on May 08, 2024, 02:41:20usually hits error "OutOfMemory"
Quote from: spasi on May 09, 2024, 11:02:06- Run the code as is, but do not call glBufferData.->
Quote from: spasi on May 09, 2024, 11:02:06- Replace the temporary FloatBuffer with a single, fixed buffer that is being reused between calls.->Memory consumption is a about 20 % lower (fixed FloatBuffer is 1024).
Quote from: spasi on May 09, 2024, 11:02:06How many times do you call storeDataInAttributeList and with how much data?thousands -> a few hundred thousand, a few 2d vertices (lines) to about a few hundred (polylines).