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."