# Running Leak Suspect Report

In the toolbar select the drop-down menu Run Expert System Test > Leak Suspects .

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 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 route 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. 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 the biggest few objects are shown by Biggest Instances . If there are many objects and none uses more than 1% of the leak then this is omitted.

If the leak suspect is a group of objects then the query attempts to find an interesting (not a standard Java class `java.` ) 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. 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. If the root of this path is a thread then some interesting thread related information is also extracted.

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

There is also a leak suspects report made by comparing two snapshots. This is available via Leak Identification > Compare Snapshots Leak Report or from the Overview panel as Leak Suspects by Snapshot Comparison which includes leak suspects and a system overview from comparing two snapshots. This works by comparing the dominator tree of the two snapshots, identifying big changes in the size of items in the dominator tree as possible leaks.

Examples of summaries of leak suspects:

`Problem Suspect 1
One instance of "org.eclipse.mat.ui.compare.CompareBasketView$ComparePolicy"
loaded by "org.eclipse.mat.ui" occupies 487,234,584 (28.60%) bytes.
The memory is accumulated in one instance of "java.lang.Object[]",
loaded by "<system class loader>", which occupies 487,234,328 (28.60%) bytes.
Keywords
org.eclipse.mat.ui.compare.CompareBasketView$ComparePolicy
org.eclipse.mat.ui
java.lang.Object[]
`

`Problem Suspect 2
The thread java.lang.Thread @ 0xe0c2ac98 main keeps local variables with total size 5,394,048 (68.41%) bytes.
The memory is accumulated in one instance of "org.eclipse.mat.tests.CreateCollectionDump", loaded by "jdk.internal.loader.ClassLoaders$AppClassLoader @ 0xe0c137a0", which occupies 5,393,416 (68.40%) bytes.
The stacktrace of this Thread is available. See stacktrace. See stacktrace with involved local variables.
Keywords
org.eclipse.mat.tests.CreateCollectionDump
jdk.internal.loader.ClassLoaders$AppClassLoader @ 0xe0c137a0
org.eclipse.mat.tests.CreateCollectionDump.main([Ljava/lang/String;)V
CreateCollectionDump.java:174
`

`Problem Suspect 3
The classloader/component "com.ibm.dtfj.j9" occupies 551,743,560 (55.09%) bytes.
The memory is accumulated in one instance of "com.ibm.j9ddr.corereaders.minidump.WindowsProcessAddressSpace",
loaded by "com.ibm.dtfj.j9", which occupies 540,840,744 (54.00%) bytes.
Keywords
com.ibm.dtfj.j9
com.ibm.j9ddr.corereaders.minidump.WindowsProcessAddressSpace
`

`Problem Suspect 4
The class "java.lang.ref.Finalizer", loaded by "<system class loader>",
occupies 188,628,792 (18.83%) bytes.
The memory is accumulated in one instance of "com.ibm.dtfj.java.j9.JavaRuntime",
loaded by "com.ibm.dtfj.j9", which occupies 186,736,528 (18.64%) bytes.
Keywords
java.lang.ref.Finalizer
com.ibm.dtfj.java.j9.JavaRuntime
com.ibm.dtfj.j9
`

`Problem Suspect 5
19,414,929 instances of "int[]",
loaded by "<system class loader>" occupy 716,412,176 (42.05%) bytes.
These instances are referenced from one instance of "java.lang.Object[]",
loaded by "<system class loader>", which occupies 77,659,616 (4.56%) bytes.
Keywords
int[]
java.lang.Object[]
`

`Problem Suspect 6
2 instances of "org.eclipse.mat.parser.internal.SnapshotImpl",
loaded by "org.eclipse.mat.parser" occupy 261,910,656 (15.37%) bytes.
Biggest instances:
org.eclipse.mat.parser.internal.SnapshotImpl @ 0x6ff5af620 - 136,622,272 (8.02%) bytes.
org.eclipse.mat.parser.internal.SnapshotImpl @ 0x6c2f6ce38 - 125,288,384 (7.35%) bytes.
These instances are referenced from one instance of "org.eclipse.swt.widgets.Display",
loaded by "org.eclipse.swt", which occupies 20,104 (0.00%) bytes.
Keywords
org.eclipse.mat.parser.internal.SnapshotImpl
org.eclipse.mat.parser
org.eclipse.swt.widgets.Display
org.eclipse.swt
`

`Problem Suspect 7
1,868 instances of "java.lang.Class",
loaded by "<system class loader>" occupy 1,000,176 (12.68%) bytes.
Biggest instances:
class sun.util.calendar.ZoneInfoFile @ 0xffe065a0 - 151,368 (1.92%) bytes.
Keywords
java.lang.Class
`

`Problem Suspect 8
One instance of "java.util.concurrent.ForkJoinTask[]" loaded by "<system class loader>" occupies 279.27 MB (40.12%) bytes. The instance is referenced by java.util.concurrent.ForkJoinWorkerThread @ 0xd53a1bf0 ForkJoinPool.commonPool-worker-0 , loaded by "<system class loader>".
The thread java.util.concurrent.ForkJoinWorkerThread @ 0xd53a1bf0 ForkJoinPool.commonPool-worker-0 keeps local variables with total size 120.71 KB (0.02%) bytes.
The memory is accumulated in one instance of "java.util.concurrent.ForkJoinTask[]", loaded by "<system class loader>", which occupies 279.27 MB (40.12%) bytes.
The stacktrace of this Thread is available. See stacktrace. See stacktrace with involved local variables.
Keywords
java.util.concurrent.ForkJoinTask[]
java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks()V
ForkJoinPool.java:1040
`