Skip to main content

Tracking Down Memory Leaks, Part 2

Posted by gsporar on May 1, 2007 at 9:41 PM PDT

Part 2 of the memory leak article
I wrote with Sundar has been published. This
time around we added our co-worker Frank Kieviet as an additional author.
As with Part 1
of the article, the editors at Software Test &
Performance
magazine provided a more descriptive title: "It's
Not Just The Younger Generations." It begins on page 26 of
of the May, 2007 issue.

Part 1 of the article discussed what I refer to as "regular" memory
leaks. In other words, objects allocated by an application's code that are no longer being used
but that continue to live on the heap because of an inadvertent
reference that prevents the vitual machine's garbage collector
from removing them.

I refer to these as "regular" memory leaks
for two reasons. First of all, they happen all too often. Second,
the objects are on the "regular" part of the heap, which is
used to hold objects allocated by using new. In other words, the
portion of the heap controlled by the -Xmx and -Xms flags. For folks who are
really into the implementation details of the garbage collector, these
are the young and tenured generations of the heap.

The permanent generation, on the other hand, is a very different beast.
It is primarily used by the virtual machine to store things like class
data. So just the running of a Java application causes the
usage of permanent generation memory - the application code itself
does not have to do anything.

This indirect link between application behavior and usage of
the permanent generation can make tracking down memory leaks in
the permanent generation
very difficult. Frank Kieviet has significant
experience tracking down these sorts of problems and his contribution
to the article was invaluable.

If you are attending JavaOne next week Frank and Edward Chou will be
doing a BOF on the topic of permanent generation memory leaks. I'm hoping
Frank and Edward will show up for JavaOne one day early in order to
attend NetBeans Day on May 7. If you plan to be in the San Francisco
area that day, be sure to join us -
it is a free event, but you do have to register.

One final note - I spotted two typos that snuck into the article during the layout process:

  • On page 29 this command line flag is specified: "XX:+TraceClassUnloading" and it should begin with a hyphen "-XX:+TraceClassUnloading"

  • On page 30 there is a sentence that starts "With JDK 6, simply use the new-dump option...." A space character got removed - it should read "With JDK 6, simply use the new -dump option...."