[solved] I need help for sun.misc.launcher$appclassloader memory leak

General Discussion
1

I can’t find the reason for the memory leak and no Idea how to solve it…

1- a singleton design pattern class can make a memory leak?
2- a private, not static ArrayList that contains JME Nodes(some characters that removed from the list when they dead) in a singleton class can collect by GC?

best regards.

2

What is your evidence that you have a memory leak?

2 Likes
3

I added 100 new character models to the scene graph. then I killed them (played animations and sounds and at the end detached from the root node).
I check the memory before and after this process but the graph is not going down when I pressed the run GC button of visual VM.

and also if I do it again (adding new nodes and remove them) used heap size grows until it throws out of memory exception, CPU used a lot and the GC graph is trying so hard to collect the unused memory but the result is very low.
is not it a memory leak?

1 Like
4

Could you please prepare TestCase we can run?

2 Likes
5

I agree on the test case.

Chances are pretty good that the test case will work fine. Then you can tell us about if you have any custom controls, etc… Stock JME code won’t do this. I add/detach things from the scene graph all the time without issue and I do this constantly and have run apps for many hours with them not going above 33% memory usage (out of 1 gig).

Edit: else if you are already in the profiler, take a memory snapshot and see what’s hanging around, what’s referring to it, what code created it, etc… which is what I’d do if it were my own code. (I haven’t run a memory profiler in more than 7 years so I don’t know the specific ‘how’ details anymore… but even that should tell you something.)

1 Like
6

For everybody’s reference in topic:

  • Using VisualVM, you’ll want to take a “heap dump.”
  • Once the heap dump is loaded, sort by retained size. This may take a few minutes.
  • VisualVM has several built in sort and filter options so you don’t have to look through every single object. Make sure that you’re listing by object, not class. Then focus on the “dominators.” These are individual objects that are the sole blocker preventing GC of large chunks of the object graph.
3 Likes
7

thank you all, I checked the result of the references and GC roots to the sun.misc.launcher$appclassloader in VisualVM and found the problem in part of my code where I never thought it is there.

1 Like