I just wanted to take the opportunity to thank everybody who joined our technical session at Java One 2008 - “Automated Heap Dump Analysis for Developers, Testers, and Support Employees”.
I was very happy to see more than 400 people in the room, despite of the fact that the session was in the afternoon of the very last day of the conference. Thank you! It was a real pleasure for us the speakers.

As a project that is relatively new at Eclipse (was recently contributed by SAP) we are very interested to get some feedback from you - both about our JavaOne session and about the tool.

So I hope that we can get some comments added to this blog from the people who saw the session @ Java One and want to spend several minutes to give us their valuable opinion.

And for any feedback, suggestions or comments on the tool itself, please use our newsgroups.

For anybody who is interested in the topic and in the Memory Analyzer tool, but didn’t have the chance to play with it yet - our project page is http://www.eclipse.org/mat/.

Memory Analyzer - is a powerful Java heap analyzer. It makes it possible to find a memory leak or reduce memory consumption by looking into the heap dump only. Our wiki page provides detailed information on how to acquire a heap dump.

Sometimes you open a heap dump in Memory Analyzer and see nothing … but a pile of small objects:

As overview pane shows, the majority of retained memory is more or less equally distributed among several objects, which makes it difficult to see a suspect for a memory leak at first sight.

Grouping in Dominator Tree

The pie in the overview pane is a graphical representation of the Dominator Tree, which you can open from the toolbar using the button

The Dominator Tree is built out of an object graph. Each object in the tree is responsible for keeping its children alive. The tree is sorted in descending order according to the size an object retains in memory.
Now, if we group the dominator tree by class (using the drop-down toolbar menu), we will see a different picture:

We can see that 700 objects of class com.foo.bar.menu.MenuEntry retain 46 % of the total heap space. Suddenly we see an unequal distribution of the retained memory.
How is it possible that we see it only now? The answer is that in this heap dump we do not have one single big object, but a group of leaking objects. Remember, the overview page of the heap dump only displays the distribution of retained memory heap on a per-object basis. So, when we group the dominator tree by class, we group our leaking objects to their origin class and thus get an accumulated retained heap.
Let’s find out who is referencing all those com.foo.bar.menu.MenuEntry objects. For this select List objects –> with incoming references from the context menu. As a result we will get an object reference graph:

If we drill down into the com.foo.bar.menu.MenuEntry, we can see the chain of objects referencing our suspect. Unfortunately, in this case it is not really helpful as we see only a LinkedList structure.

Grouping referrers to the class level

As we have seen looking at the incoming references graph for our suspect objects did not reveal a lot. Grouping referrers to class level might be more helpful. This operation is performed via a context menu. Back in the dominator tree grouped by class, right-click on our suspect com.foo.bar.menu.MenuEntry and select Show objects by class –> by incoming references:

Grouping referrers by class allows us to see a simple and easy to understand reference chain:

We can now see, that class com.foo.bar.menu.MenuEntry is referenced by a LinkedListEntry, which we already knew. But as we continue we see that this entry is again referenced by a LinkedListEntry (this is the head of the LinkedList) and by the LinkedList. LinkedList itself is referenced by two classes, one of which is of no interest as it is from the java.* package (which for now we assume to be unproblematic). The other one, however, is of interest.
The easiest way to find out what keeps our memory leaking group of objects alive in the heap is to check the path to the garbage collection roots. However, paths to garbage collection roots can only be found for a single object but we are interested in finding a common chain of references to a group of objects. Well, this is also possible.

Merging Paths to Garbage Collection Roots

The Merged Paths to GC Roots view shows the shortest paths from the GC roots to each instance of the selected class. You can open this heap editor using the context menu Merge Shortest Paths to GC Roots on the com.foo.bar.menu.MenuEntry class instance:

This operation explores all the paths from the different objects to their GC roots at once and finds a common chain of references for this group of objects. It is a common procedure to exclude weak and soft references from the result as they cannot be the main reason of keeping the objects of interest alive.

There we got the reason: one instance of the class com.foo.bar.menu.FoodSupplies keeps in memory 700 instances of the class com.foo.bar.menu.MenuEntry. Now is the right time to check what is going on in the code and fix the problem.

Conclusion

Apparently, Memory Analyzer has more aggregation features to offer. Some of them will be covered in our future blogs.

A memory leak is an unintentional memory usage. In Java programs, leaks are objects which are not used/needed anymore, but which are still reachable and therefore are not removed by the Garbage Collector. In our case this means that instances of WorkbenchWindow are not garbage collected even though the window is closed and the workbench window instance is not needed anymore.

Once we got hold of the leaking object, we have to determine why it is still around. To do this, we follow the reference chain from the object to the Garbage Collection (GC) roots. GC roots are objects which are assumed to be reachable by the virtual machine: objects on the call stack of the current thread (e.g. method parameters and local variables), the thread itself and classes loaded by the system class loader. Looking at that reference path, we can decide which reference should be removed as it is accidentally keeping the leaking object alive.

Enough theory, let’s get started…

Reproduce the Leak

I did use an Eclipse 3.4M6a milestone build and reproduced the leak by using a default launch configuration for the product org.eclipse.platform.ide. Then I started the IDE, opened a new window via Window -> New Window and closed the window right away.

Acquire a Heap Dump

Now I need to create a heap dump. There are many ways to do this. On Windows, I find the easiest way is to use JRE 6 and JConsole. You can configure your JRE in the Eclipse Preferences: Java -> Installed JREs. Please note: you cannot use JConsole on JRE 5 VMs because the MBean does not provide the operation to write a heap dump.

Start <jre6>/bin/jconsole.exe and select the running Eclipse IDE:

Then, select the operation dumpHeap from the com.sun.management.HotSpotDiagnostic MBean. The first parameter p0 is the full path to the heap dump file. Make sure you give it the file extension .hprof. The second parameter p1 should be left at true as we are only interested in live objects.

Open the Heap Dump in the Memory Analyzer

Start the Memory Analyzer and select “Open Heap Dump…” from the File menu. The heap dump will be parsed and a number of index files is created next to the dump. Those are needed for fast access to the data in the dump.

The difficult part is to find the leaking object. In our case we can make it easy: we specifically test the “New Window” scenario so that’s what we are looking for. And we can assume some implementation knowledge: a workbench window is represented by the class WorkbenchWindow. So let’s open the histogram and filter (the first row) by that class:

Et voilà, we have 2 instances even though we already closed the second window. Let’s have a look at those two objects. I choose the incoming references to see who is immediately referencing these WorkbenchWindow instances:

To decide which of the objects is good and which is bad, I open the incoming references. The second object is referenced by the Workbench via activeWorkbenchWindow. This looks okay, so the first one is suspicious.

Path to Garbage Collection Roots

Via the context menu, I select to display the shortest path to the GC roots. I am excluding weak and soft references, because they cannot be the root cause for keeping the WorkbenchWindow alive.

Expanding the view a little bit, I get the following picture:

What does it mean? These are the reference chains keeping the WorkbenchWindow alive. The name of the member variable that is holding the reference is printed in bold.

Analyzing the First Reference Path

To make sense of this, we need knowledge of the coding. I am not familiar with the code myself, but let’s see what we can dig up.

Looking at the first reference chain, I see the attribute listenerList of the Command object (A). I take a closer look because registering a listener and then forgetting to unregister the listener is a very easy way to create a leak. The Command objects are global and hence independent of the workbench window. A little further up, there is the anonymous inner class CommandAction$1 (B) in the listener list, which references the WorkbenchCommandAction (C) via this$0 (a reference automatically generated for non-static inner classes). Checking the source code, I know that WorkbenchCommandAction extends CommandAction. This is also a common pattern: the listener is an anonymous inner class.

Check if Listener is Removed

Okay, let’s get our hands dirty and take a look at the CommandAction code. This is the init method where we find the listener registration:

The listener itself is created in the getCommandListener method. Note that a reference is kept as member variable. The reference is needed to unregister the listener.

So let’s take a look at the dispose method:

Yes, the listener is properly unregistered. No problem with this code.

Inspecting the Leak Object…

We need to know who forgets to call the dispose on the CommandAction. So let’s go back and have a look at the Command object. The Object Inspector (open the view via Window->Show View… if not yet open) shows the content of all member attributes. There we find the id attribute.

A quick code search with that id brings us to the ActionFactory which creates the WindowCommandAction object:

Another search for references brings us to the WorkbenchActionBuilder. Looking at the code, the action is created and a reference is kept. But in the dispose method of the WorkbenchActionBuilder that reference is only nulled and not disposed. But after all, that’s just a one line code change to fix. (I attached a patch to the bug.)

Analyzing the Second Reference Path

It turns out that the second path has a very similar cause:

Again, a WorkbenchCommandAction is involved. This time a class name in the reference chain gives us the hint: The BaseNewWizardMenu class uses the ActionFactory to create a command but does not dispose it properly. That is another one liner to fix.

If I now run the same scenario again, I only find one instance of the WorkbenchWindow in the histogram.

Conclusion

I hope you enjoyed this blog about analyzing a memory leak. Admittedly, we already knew what was leaking (the workbench window) and therefore could concentrate on the problem right away. One can use this approach for example when developing a new editor, view, plugin, perspective, etc. etc.

So what if you do not know what is leaking? Well, let me say this for now: let the leak grow until it shows up in the biggest objects. That is usually the case if your virtual machine throws an OutOfMemory (OoM) error. Make sure you configured your VM to write a heap dump on OoM (-XX:+HeapDumpOnOutOfMemoryError). Then run the Memory Analyzer.

Comments and Feedbacks are very welcome!

Some links: Screenshots, Download, Wiki.

For those who have not been able to attend our EclipseCon session, you might want to join us at JAX or JavaOne. Here are the dates:

JAX, Wiesbaden, Germany
Automatisierte Speicheranalyse: Auf der Jagd nach den Speicherfressern
Speaker: Erwin Margewitsch
Wednesday, 23 April 2008, 10:00-11:00

JavaOne, San Francisco, CA, USA
Automated Heap Dump Analysis for Developers, Testers, and Support Employees
Speakers: Krum Tsvetkov, Andreas Buchen
Friday, 9 May 2008, 11:30-12:30

Please leave us your comments and feedbacks!