Tracking Down Memory Leaks, Part 1

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 your situation.

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 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.