Hello,
i'm trying to get rid off all my memory leaks. Do you have some best practices to submit ?
I mean,
Each time i do not need a Node anymore What should i do ?
here is what i'm doing for the moment:
Node parentNode = node.getParent();
parentNode.detachChild(node);
node.detachAllChildren();
parentNode.updateRenderState();
memory leaks usually don't happen in the java layer.
so imho you only have to take care if you're doing some buffers black magic. otherwise the jvm will take care of it.
in some cases, bad programming could also cause memory to be allocated without being released (not releasing references). but jme itself is quite clean , so you will only have to worry about your own code 
Ok, but let say i created a lot of objects in my scene and i want to remove them one at a time. What should i use to be sure to avoid leaks…
Always question every "new" call you make, especially in the case of math classes and states. In most cases, the object is either already there for you to modify, or you can create a shared object to do the work of many.
voldor said:
Ok, but let say i created a lot of objects in my scene and i want to remove them one at a time. What should i use to be sure to avoid leaks...
Thanks for your help, I will let you know if it solves my issues of canstant increase of memory usage
Watch out for ImageIcon's - these are cached
Watch out for textures created with the TextureCache, you will need to release textures you no longer want manually.
Watch out for large collections, have known some jvm implementations - IBM's in particular that will give up looking for weak references in large collections. Ensure you remove all the items manually if you suspect this, not using collections.clear
voldor: Are you talking about a memory leak or allocation of objects that your JVM runs out of memory?
With the allocation of objects in JME, DF wrote a great SpatialPool that you can use.
When I was creating objects before the dynamic allocation from loading the objects etc would cause my memory allocation to go up quite a bit since the gc was never collecting all of the objects created but not used (since there was a link between the object used and the object creation… that was my bad). Now, the memory use is quite a bit less for multiple objects.
My previous object creation (before using the SpatialPool) could be considered a memory leak, b/c you're always increasing the memory usage, but not gc'ing the objects that aren't needed.
In the case of the node usage, if I'm not using a node anymore I detach it and set that object to null. Most of the time it's an instance that I won't use it again.
For example, in one display that I have, I have a clock that increments numbers for the hours, minutes and seconds with two numbers per… PLUS I have the clock that displays in a dynamic circular fashion (http://gerbildrop.com/cm3demeter/xbgScreenshots/dradisClockExample1.png)
The numbers are all loaded with the circular images when the class loads (since I haven't rewritten my resource object yet).
When I attach the clock numbers they each have a name that corresponds to their function, then when I update I detach the ones I need to:
rootNode.detachChildNamed("hours");
rootNode.updateRenderState();
since the clock example is quite a bit different b/c of the clock logic I don't always have to detach hours… I mean once an hour:)
I then attach the new node for hours.
In theory, I suppose, that the nodes could be replaced by name… but I haven't tried that yet. e.g. instead of detaching the hours node, just attaching the new node named hours… but I'm not sure how that works with the JME scenegraph.
Doesn't a Profiler help finding memory leaks? For instance, Netbeans IDE has a profiler which neatly shows where there are leaks.
it's been a while since i last tested the eclipse profiler (have crappy hardware and only 512 ram), but it might be worth a try.
+1 to Darklord…
If you think you are having problems with Memory, profile, profile, profile. If you attempt to optimize memory/performance without profiling, you'll find out your assumptions are almost always wrong.
