Fortunately, now we have a decent free tool that integrates with the Eclipse known as Memory Analyzer, or MAT. Installation can be done via the standard update sites, just type memory analyzer and follow the installation instructions. Charts feature isnât required if all you want to do is track down your problem areas. And Iâll assume you either have a heap dump generated on an OutOfMemory or have connected to a live vm to extract one. If you donât have one and the vm is running, you can use MAT to extract one. Just look in File menu, Acquire Heap Dump option.
When you first open your heap dump, MAT will ask if youâd like to run one of their canned reports.
This likely isnât worth your while. I havenât found them to provide any meaningful insight. Perhaps if your application is very simple, the problem is obvious or in the case of tuning, the Component Report, these reports might be worth a shot. But likely your best starting point is to take a look at the dominator tree.
Either use the icon, the Dominator Tree link under the Biggest Objects by Retained Size section, or select it as an Action.
First of all, the default Dominator Tree view shows single objects. If nothing jumps out at you immediately, you can take one or both of the following actions.
- Select the Group Result ByâĶ icon and group by class
- Right click the header row and select Columns -> Edit Filter -> Class Name or start typing in the Regex row if available
This allows you to see # of Objects of each type and also filter them by your code, or perhaps other package name patterns that you suspect may be causing problems. Once youâve found an entry that youâd like to dive into, you have several ways of getting additional information. If you expand the class selection, youâll be able to see what references the objects are holding and their sizes â the retained objects. And MAT is smart enough that the filters you may have applied do not extend to these retained objects.
If you right click the class entry and select âShow Retained Setâ, you will see all the retained objects of everything ultimately contained by that object, a very convenient view that can help you quickly pinpoint a problem class.
Perhaps you canât understand why there are so many instances of a particular object type in your heap dump, feeling that they should be short-lived or limited in quantity. The âPath to GC Rootsâ (available when selecting a single object instance) and âMerge Shortest Path to GC Rootsâ (for multiple instances) give you a view of the objects in question that allows you to see which objects are maintaining references to the object(s) in question.
With these tools, views and filters, Iâve not found it necessary to use some of the other features of MAT but by all means, take a look at OQL (SQL style ability to query the heap details), Histograms and even specialized Java Collections usage details.
Once you have a class youâd like to investigate at the code level, assuming you have the source code in your workspace, right-click the class from any of these views and select âOpen Source Fileâ.
Iâve been able to successfully use MAT to pinpoint memory problems in applications that I had very little exposure to. It provides a concrete memory overview that doesnât show bias when long-time project developers may be inclined to do so. If you happen to have a decent understanding of your application, even better. That knowledge will help you put context around some of the data MAT shows you. Whatâs your experience with MAT been?
Reference: Eclipse and Memory Analyzer (MAT) from our JCG partners at the Carfey Software blog.
