[SOLVED] MemoryLeak with LWJGLBufferAllocator

Hi,
jME now has the awesome feature to use the lwjgl buffer allocator with jemalloc. Thanks to @javasabr :slight_smile:

This was the PR: implemented LWJGL3 BufferAllocator by JavaSaBr 路 Pull Request #588 路 jMonkeyEngine/jmonkeyengine 路 GitHub

But there is still some work to do. Especially with all meshes that were detached from the scene graph and aren鈥檛 needed anymore. If a mesh was detached, the buffers allocated via BufferUtils (and therefore jemalloc at the end) are not destroyed. This causes a memory leak and I bet there are still some other places where buffer needs to be destroyed correctly.

Has someone already an idea to this problem?

I also think about this

2 Likes

Actually they should at least be destroyed once the GC feels like it, but yeah if we had a faste explicit system that can fast kill them in a generic way, that would be pretty nice

maybe we can make use of Object.finalize()? But its not guaranteed that this method is always called.

But I have some ideas how I can solve this problem鈥

2 Likes

finalize is worse (it has a lot of ugly implications, and requires 2 gc roundtrips), if necessary a phantomqueue (look at the tracking in bufferutils) is a way better way. Actually that could be replicated similar for that allocator. That however does not solve the problem of the gc only running rarely, but it should not overflow anymore.

My understanding was that the NativeObjects that JME manages (that generally hold these buffers) are garbage collected using references already.

Has anyone confirmed that this is actually an issue? Or is it just something missing in the new allocator?

I know with the regular one that the buffers GC just fine. So whatever you end up having to do will be allocator specific.

Native objects don鈥檛 work in the case when GC can鈥檛 free memory of allocated direct buffers.

http://javadoc.jmonkeyengine.org/com/jme3/util/NativeObject.html#deleteNativeBuffers--

I鈥檓 just saying鈥 it seems like there are already hooks in place for this.

At any rate, if this special allocator creates buffers that Java can鈥檛 free normally then ALL of the changes should be in the special allocator. They do not belong in BufferUtils directly as they only apply to the special allocator鈥 the one with the issue.

1 Like

we always have a realObj is null when our native object was deleted from GC.

2 Likes