Plugging the leaks: Blog #2 Traditional approaches to troubleshooting Java Memory Leaks

[#1]

This blog was written by Piotr Findeisen, HP Diagnostics Senior Software Engineer.

Java Profilers

So far, application users had limited options while struggling with Java memory leak issues. The first one was to use Java profiling tools. There is a large variety of such tools available, with examples including JProfiler, WebLogic Memory Leak Detector, and countless others.

These tools have been designed for desktop usage, require intensive user interaction, and share one common disadvantage. Even if they scale up (i.e. do not crash), their overhead is so huge that they are simply unusable in production environments.

Heap Dump with Off-line Analysis

Another popular category of tools for diagnosing memory leaks is Java heap analyzers. Examples include Oracle AD4J, IBM MDD4J, YourKit, dynaTrace, SAP Memory Analyzer, Eclipse Memory Analyzer and many others. These tools rely on heap dumps from the JVM. The dumps then may be copied to another system for a thorough analysis.

There are some issues with this approach, too. The heap dump is usually performed right before the JVM goes down after running out of memory, which is too late for the IT personnel to come up with any contingency actions. And while some JVMs allow periodical heap dumps, these are costly operations, freezing the application even up to few minutes (for really large heaps) at a time. Many applications work under time constraints that do not allow such delays.

The second major drawback of this approach is that no matter how smart the analysis of the object reference graph is, it can tell only things about the data structures, but not about the faulty code that is the root cause of the memory leak. Therefore the user is still required to be familiar with the code, to do some guesswork, and to try identifying the bad code either by code inspection or by running additional tests.

Please also note that this approach is only suitable for a reactive approach. It is hard to imagine anyone using periodical heap dump analysis to detect and pinpoint memory leaks proactively.

Collection Objects Monitoring

Finally, there are a number of tools for monitoring Java applications in production environment which try to address the problem of Java memory leaks. These tools work in real-time, analyzing Java collection objects (such as ArrayList or HashMap) and reporting large or fast-growing objects (the “leak suspects”) to the user. However, their overhead is often too large to be used in production environment. Some vendors even decided to disable memory analysis features when the tool is installed out-of-the-box.

A rough estimate for the overhead of some of the collection objects monitoring tools is 10% or more, but it may heavily depend on the configuration. Some tools, to limit the overhead, offer the capability to limit the scope of collection objects monitoring to selected modules, jarfiles, or Java packages. Alas, this creates a chicken-and-egg problem for the users: they need to know where the leaks are in their application before engaging the tool to find them!

Indeed, the required guess-work and/or the overhead, make these tools more suitable for a pre-production environment than a production environment. Furthermore, these tools do only a partial job when it comes to identifying the faulty code. They provide the allocation site (with a stack trace) for each leak suspect. However, for complex applications, the collection object allocation site may not be related at all to the faulty logic that is responsible for the leak.

The 3rd and final part of this blog series will go into details about a new approach for pinpointing Java Memory Leaks.

This blog was written by Piotr Findeisen, HP Diagnostics Senior Software Engineer.

[#2]

I love this post very much, please keep sharing of knowledges with us.

[#3]

thanks for your great posting,i love this post.