Posted by gsporar
on September 23, 2006 at 3:53 PM PDT
As promised, a recap of my session at JavaZone
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.
- 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 .
- 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.
- 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.
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 .