BOF-2417, Memory Leaks in Java Applications: Different Tools for Different Types of Leaks
The BOF went well. There were about 300 people who showed up, which is pretty good
considering that the
After Dark party was going on.
The idea behind this presentation
is that when you want to debug a memory leak there are two techniques you can use:
walking the heap and instrumentation. Each approach has strengths and weaknesses
and in my view there is not one correct technique for all situations. The majority
of the presentation was spent on two case studies from applications I have debugged, one where I used
a heap walker and one where I used instrumentation. As promised, the slides are here.
The JDK5 Trouble-Shooting and Diagnostic Guide.
Provides information on the different tools available in the JDK for tracking
down memory leaks and other performance problems.
One topic that I mentioned briefly was the idea of using specific coding techniques
and unit tests to prevent memory leaks from making it into production code. As
I said at the time, this deserves a BOF of its own. One tool that can help, however,
is the Insane Library.
If you are interested in Insane, also check out this blog entry
from Tim Boudreau.
YourKit was the profiler I used in my heap walker demo.
The NetBeans Profiler
was used in my instrumentation demo.
And finally, a few additional thoughts on some of the questions that were asked.
- What's the best way to debug a problem where perm gen is running out of space? I got
this answer from Alan Bateman: "The jmap -permstat option might be useful.
It prints statistics for the objects in the permanent generation. This includes
the number of classes loaded by each loader, and the approximate number of
bytes consumed by meta-data for the classes loaded by each loader. This utility
was added in J2SE 5.0 and was updated in Mustang to also print out the number of
interned strings (interned strings are also stored in the perm gen)."
- What should I do if I am not getting an out of memory error from the JVM, but Windows
is swapping like crazy when my Java application runs? In general, this sounds
like a problem with not enough RAM and/or too many applications running at the
same time. The Windows Task Manager would be the first thing I would use to take
a look at total system memory usage and it also displays memory usage by process.
Further, Alan Bateman suggests that in some situations it might be worth
decreasing the size of the heap, (by reducing the value of -Xmx).
- How do I debug memory leaks in JNI code? I totally punted on this
question, because I have never had to deal with this problem in a production
application. Charlie Hunt suggests: "Any time I wanted to track down
something in JNI code related to performance, I used the
Sun Studio Collector / Analyzer."