Posted by gsporar
on April 1, 2007 at 5:43 PM PDT
Have you seen an OutOfMemoryError while running your Java application? Not sure how to get started figuring out the cause? Sundar and I have just published an article that might be able to help.
The April, 2007 issue
of Software Test & Performance magazine has an article
that I wrote with Sundar .
Our original title was not very snazzy:
"Tracking Down Memory Leaks, Part 1," so they changed it to "Baffled
by Brain Drain In Your Java Apps?"
The idea behind it is drawn from several sources. I did a BOF last
year at JavaOne where I talked about the different types of tools
available for tracking down memory leaks in Java applications. I
firmly believe that the tool/technique you should use depends upon
It is important to note that in that BOF I was only talking about
what I refer to as memory leaks on the "regular" heap. In other words,
leaks that occur in the permanent generation were out of scope. In
part that was because I don't have much real-world experience dealing with
problems in the permanent generation.
When the article was proposed it seemed to me that permanent generation
leaks needed to be included. That naturally led me to Sundar, who had
been writing really excellent blog entries on how to use
jhat (an essential
tool for tracking down permanent generation leaks).
Once we started pulling everything together, it became obvious that it
was too much for one article, so this first article is about "regular"
heap memory leaks only. The May issue should contain Part 2 which
will cover permanent generation memory leaks. For that Part 2 article
we also added the very knowledgeable
Frank Kieviet as an additional author. Frank
had been writing some excellent blogs
about the pains of debugging permanent generation memory leaks.
One of the nice things about Software Test & Performance magazine
is they make their print edition available as a .pdf file. Reading
the article in the .pdf file makes it easy to click on all the links
we provide. Gathering together all those links was one of the
main things I wanted to accomplish with this article.
I had also been hoping to write an error-free article. Alas, that did
not happen. This always seems to be the case... we reviewed it and
proofread it over and over again. Alas, two errors and one typo
did creep in:
In the description of the output from the -verbose:gc command
line option, there is this sentence: "The number in parentheses
is the total amount of free heap space." That is incorrect.
It is the total amount of heap space (not counting
the permanent generation), minus one of the
survivor spaces. More information here .
In the section on generating a heap memory snapshot file, there
is this sentence: "A Ctrl-\ (or Ctrl-Break in Windows) at the
console of your application will end the application and
create the snapshot file." That is partially correct - the
snapshot file will get created but the application is not
terminated and will continue to run.
The typo is pretty minor. This command line flag is specified:
"Xrunhprof:heap=dump,format=b" and it should begin with a
hyphen, in other words: "-Xrunhprof:heap=dump,format=b" That
problem got introduced during the production process at the magazine.
That only one minor typo snuck in is a testament to the quality
controls at the magazine. Further, I really enjoyed the back-and-forth
of the editing process with Eddie Correia.
One final note: at this year's JavaOne, Frank and Edward Chou will be
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 .