Running Leak Suspect Report

As a result an HTML report will be opened. It contains an overview of the heap dump and leak suspect info.

This report will be stored together with the heap dump and can be displayed when you open the heap dump again.

Some of the sections in the leak suspects report have links to rerun the individual queries which make up the report. This can be useful for further analysis. See Pie Chart Links for links from pie charts.

The standard leak suspects report operates just using the heap dump data, which is a snapshot from a particular moment. It does not use any time information as to when objects were allocated.

The starting point is the dominator tree . The biggest items at the top level of the dominator tree are analyzed, and if an item retains a significant amount of memory (default is 10%) then that item could be the cause of the memory leak because if it were no longer referenced then all that memory could be freed.

It could be that single objects do not retain a significant amount of memory but many objects all of one type do. This is a second class of leak suspect. This type is found using the dominator tree, grouped by class.

Further analysis is then done on each leak suspect. For a single object leak suspect the retained objects are analyzed in the dominator tree to see if there is an accumulation point . An accumulation point is an object with a big difference between the retained size of itself and the largest retained size of a child object. These are places where the memory of many small objects is accumulated under one object.

If the leak suspect is a thread then thread related information such as the call stack is shown, together with interesting stack frames which have local variables referring to objects on the path to the accumulation point. If the leak suspect is a class loader then this is mentioned as being an interesting component of the application. If the leak suspect is a class then its class loader is mentioned as being an interesting component of the application.

The Shortest Paths To the Accumulation Point shows a path from a garbage collection root to the accumulation point. There will be other paths, otherwise an object on the path would retain the leak suspect, so itself would be considered a leak suspect. If the root is a thread object then thread related information is also shown.

The Accumulated Objects in Dominator Tree shows the dominator tree from the leak suspect to the accumulation point and also the objects that the accumulation point retains. This helps understand the context of the leak, and what is being accumulated. The Accumulated Objects by Class in Dominator Tree shows just the children in the dominator tree of the accumulation point, grouped by class. This is useful if there are many objects, as there will be fewer types than objects. All Accumulated Objects by Class shows all the objects retained by the accumulation point, including the accumulation point, but grouped by class so it easier to see what is taking up the heap space.

If the leak suspect is a group of objects then these objects are all of the same type (class) which are at the top level of the dominator tree. Each individual object is not retained by a single other object. The query attempts to find an object which indirectly refers to all of those objects. This is also called an accumulation point but is below the leak suspects in the dominator tree, rather than above the leak suspect object in the single object case. The accumulation point is a single object through which there is a path from the GC roots to most of the objects. There will be other paths to the suspect objects, otherwise the accumulation point would be a leak suspect in its own right. The accumulation point is useful in understanding the leak as it shows one reason that the suspect objects are reachable and so alive. The standard options for the query ignore weak, soft, phantom and finalizer references when finding paths. In the report, the text Most of these instances are referenced from one instance of introduces the accumulation point.

The query also attempts to find an interesting (not a standard Java class java. javax. com.sun. jdk.) Java object which directly or indirectly refers to the accumulation point. This means that if the accumulation point is a array or object inside a standard Java collection then the interesting object might be part of the application itself. The text in the report The instance is referenced by introduces this interesting object.

If the shortest path from the GC roots to accumulation point starts with a thread, then thread related information such as the call stack is shown, together with interesting stack frames which have local variables referring to objects on the path to the accumulation point.

If the leak suspect is a group of objects then the biggest few objects are shown by Biggest Instances (Overview) which is a pie chart and Biggest Instances which is a histogram. If there are many objects and none uses more than 1% of the leak then these is omitted.

Suspect Objects by Class This is a histogram showing the suspect objects. They will all be of the same type. This section makes it easy to continue analysis of the leak by click on the link to view the suspects interactively.

All Objects by Class Retained by Suspect Objects This shows all the objects retained by the suspect and helps explain why all the memory is being used. Perhaps instead of removing the leak the problem can be reduced by changing the application code to have fewer or smaller objects referenced from the suspects.

Common Path To the Accumulation Point shows a shortest path from a GC root to the accumulation point, giving a guide as to what in the application refers to the accumulation point. By default this path ignores weak, soft, phantom and finalizer references when finding paths. If the root of this path is a thread then some interesting thread related information is also extracted.

Accumulated Objects in Dominator Tree Accumulated Objects by Class in Dominator Tree These show the accumulation point in the dominator tree, showing how it is retained, and the objects it retains.

All Accumulated Objects by Class This shows the objects retained by the accumulation point.

Reference Pattern If the leak suspect is a group of objects but there is not an accumulation point then the reference pattern shows the merged shortest paths to GC roots.

Keywords The keyword section has words which could be useful to match this problem to previous problem instances.

Learn more in this blog posting: Automated Heap Dump Analysis: Finding Memory Leaks with One Click .