[SOLVED] MemoryLeak with LWJGLBufferAllocator

Development
1

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’t 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?

2

I also think about this

2 Likes
3

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

4

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

5

http://imgur.com/a/O1V7c
But I have some ideas how I can solve this problem…

2 Likes
6

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.

7

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.

8

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

9

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

I’m 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’t 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
10

we always have a realObj is null when our native object was deleted from GC.
http://imgur.com/a/CFnQv

11
2 Likes