JavaZone Session, Memory Leaks in Java Applications: Different Tools for Different Types of Leaks

This session was the exact same as the BOF that I did this year at JavaOne. I wrote up a recap after JavaOne, which can be found here. I won't repeat that information here, instead I want to add some thoughts on some of the questions that were asked at JavaZone that I did not get asked at JavaOne.

1. Repeatedly deploying my application to Tomcat causes it to run out of perm gen space - is there a problem with perm gen usage in Tomcat? First of all, debugging memory leaks in perm gen are harder than debugging heap memory leaks. I discuss one technique over in that other blog entry, but in general the tool support is not as good as for debugging heap memory leaks. In any event, Kirk Pepperdine answered the question - he said Tomcat does have perm gen problems; in searching the bug database, I did find this entry.
2. These tools are okay for development, but what do you suggest for production environments? This is an important consideration and it highlights the difference between profiling tools intended for developers versus those that can be used in production. The developer tools typically provide more information, but they usually require that the JVM be started with special flags and they can impose a performance penalty. Things are improving on both fronts, especially in JDK6, but until then the options are a bit limited. The memory dump utilities, such as jmap are one posssibility.
3. Is there some way the compiler or an IDE could detect memory leaks? That seems unlikely to me. As Kirk pointed out, attempting to do static analysis to find a dynamic problem is not going to be very fruitful. Tom Ball might have a different view, and if so maybe he will leave a comment on this entry, but to me there is no point in writing Jackpot queries that, for example, search for calls to put() methods that use literals for keys. That's because variables are usually used to specify the key values. One way to prevent memory leaks from creeping into your code is to unit test for them, which is what I mentioned in the original entry: check out the Insane library.