Menu
I have some third library code that I run and after some time I run into OutOfMemoryError. So I fired up the Eclipse MAT and analyzed the memory. Now it seems the memory can't be disposed because there is an object that is a shown as GC root: Native Stack. Reading the documentation:
In or out parameters in native code, such as user defined JNI code or JVM internal code. This is often the case as many methods have native parts and the objects handled as method parameters become GC roots. For example, parameters used for file/network I/O methods or reflection.
Now my question is: How can I confirm that the object is used in JNI or elsewhere (i.e. how do I find the code where it is used)? Can I somehow dispose the object? What other options do I have?
Thanks for the help already!
289
Use the Eclipse Memory Analyzer If you used MAT to create the heap dump, it should be opened automatically. You may need to refresh your project (F5 on the project). Double-click the file and select the Leak Suspects Report. The overview page allows you to start the analysis of the heap dump.
To find a memory leak, you've got to look at the system's RAM usage. This can be accomplished in Windows by using the Resource Monitor. In Windows 11/10/8.1: Press Windows+R to open the Run dialog; enter "resmon" and click OK.
A GC root is a reference held in a static or local variable. A reference held in a root prevents the referenced object from being garbage collected. In VisualVM you can use the "show nearest GC root" feature to help you track down references to the object that you believe should be garbage collected.
Causes of Memory Leaks Using Unwanted Object Reference: These are the object references that are no longer needed. The garbage collector is failed to reclaim the memory because another object still refers to that unwanted object. Using Long-live Static Objects: Using static objects also leads to a memory leak.
Objects being shown as GC root: Native Stack turned out to be a problem of the Eclipse Debugger. When the application was started without the debugger (i.e. with 'run' instead of 'debug') the problem disappeared. This was also the reason that I couldn't find the code where the objects where used in JNI inside my project (cause they weren't).
Finding the real memory leak without debugging was a bit hard, but using Eclipse MAT and its 'find Leak suspects' feature helped a lot!
169
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
