The memory leak, continued

I just wanted to post a brief update on where I am with the memory leak problem that I described back on December 19. I tried out both JProfiler and YourKit until the evaluation periods ran out, and while I was not able to isolate the memory leak with either of them, but to me, one came out far ahead of the other.

To me, JProfiler is vastly superior to YourKit. I have to say, YourKit didn’t get a completely fair shake because their telemetry features only work with Java 1.5 and I’m using Java 1.4. I know it’s not impossible to write such features for Java 1.4, because JProfiler provides them, so not being able to take advantage of them was a bit frustrating for me. However, even for features that both products provide, I found JProfiler to be more robust. It does a better job of showing a comprehensive view of which objects exist and how much memory they’re using. I didn’t get to use either product enough to reach a fully informed opinion, especially because I’m not very experienced with profilers, but it sure seemed to me that JProfiler is a much more advanced tool.

I originally assumed that tracking down the memory leak would be easier if I ran tests within JUnit or in a command line program, but I actually found that it wasn’t too useful, other than to determine that there is, in fact, a memory leak. If you run transactions through the program long enough, the telemetry readout clearly shows memory usage growing. However, the problem with trying to profile the application this way is that there’s no easy way to control the execution of the code that contains the leak. You can run hundreds of transactions, all of which increase the memory usage, but the key to finding the leak is to run some transactions, let the application idle, manually trigger garbage collection, capture a baseline, and then run more transactions. It’s easier to do that running under a servlet container like Tomcat.

I found out that the command line program wasn’t best suited to my needs on my owns, but I found out about the steps for finding the problem from an expert. The thing you have to do is create a JSP or servlet that manually calls System.gc() in order to establish the baseline I mentioned above. Any objects that are no longer in use that don’t get garbage collected are the cause of the memory leak. He suggested starting up Tomcat, running a few transactions, then triggering the garbage collector and setting the memory usage baseline in the profiler. Once you run another transaction, you can then run the garbage collector again, and anything that’s hanging around in memory beyond the baseline that was set is the problem. We’ll see how that method works when I get my JProfiler license.