Skip to main content

BOF-2417, Memory Leaks in Java Applications: Different Tools for Different Types of Leaks

Posted by gsporar on May 23, 2006 at 12:38 PM PDT

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.

Additional Resources....

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.

Bloggers from whom I have learned profiling and performance tips:
Alan Bateman,
Kelly O'Hair,
Charlie Hunt,
Brian Doherty,
Scott Oaks,
Mandy Chung, and
A. Sundararajan.

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.

  1. 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)."
  2. 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).
  3. 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."