Well I ask this, because I want to get a clear view, how I will mkae my Loading/Preching System.
The exact Question is, what Classes cannot be cleaned up by the Garbage Collector itself?
Is there a way to help the Garbage Collector?
Are there any hints or tips?
The Java side of jME should be safe from memory leaks. However the OpenGL part is not in good shape. If you're using VBO or display lists, you have to manually destroy them. Textures are a bit better managed but you still need to clean the cache or delete them manually in some cases.
What about Modelloading then? Since the Importer textures the Models automatically, does it reuses them, or creates every model with textures (even if it's the same) more OpenGl stuff?
everything related to direct memory, ie coming from calls to allocateDirect, is very hard to get rid of…
I have been curious about this also before. The ByteBuffer.allocateDirect calls at least in Sun's implementation of Java as examined in the source use the sun.misc.Cleaner class to register a "deallocator" for the direct memory. Its implementation looks like a C "free" call to the allocated memory and this gets called when the java ByteBuffer object is only "phantom-reachable" (via phantom reference), in other words right before it gets GC'd. So there should be no leaks here.
All buffers used by meshes for example, vertexbuffer etc.
So if I understand you right, every simple Box can be a leak?
Are there any known workarounds?
Can this be the reason for the shared stuff?
Well what Objects are doing this?
Textures i gues, but it seems that the TextureManager gives reverences to already loaded ones.
But what about Renderstates?
Well I tried to test it, I wrote a sime test program,wich loads a 27k poly model , then detaches it, and tells the System.gc()
After like 2000 Spawn and Despawn ther was still no memory change according to the Taskmanager, so I think it might be working as you said.
sounds promising. might have been fixed or improved since a year ago then.