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.