runningleaksuspectreport.dita

<?xml version="1.0" encoding="UTF-8"?>
<!--
    Copyright (c) 2008, 2023 SAP AG and IBM Corporation.
    All rights reserved. This program and the accompanying materials
    are made available under the terms of the Eclipse Public License 2.0
    which accompanies this distribution, and is available at
    https://www.eclipse.org/legal/epl-2.0/
    
    SPDX-License-Identifier: EPL-2.0
   
    Contributors:
        SAP AG - initial API and implementation
        Andrew Johson (IBM Corporation) - fixes
 -->
<!DOCTYPE task PUBLIC "-//OASIS//DTD DITA Task//EN" "task.dtd" >
<task id="task_runningleaksuspectreport" xml:lang="en-us">
	<title>Running Leak Suspect Report</title>
	<prolog>
		<copyright>
			<copyryear year=""></copyryear>
			<copyrholder>
    		    Copyright (c) 2008, 2023 SAP AG and IBM Corporation.
			    All rights reserved. This program and the accompanying materials
			    are made available under the terms of the Eclipse Public License 2.0
			    which accompanies this distribution, and is available at
			    https://www.eclipse.org/legal/epl-2.0/
			</copyrholder>
		</copyright>
	</prolog>

	<taskbody>
		<context>
			In the toolbar select the drop-down menu
			<menucascade>
				<uicontrol>Run Expert System Test</uicontrol>
				<uicontrol>Leak Suspects</uicontrol>
			</menucascade>
			.
			<image href="../mimes/leak_report.png"
				alt="screen shot of starting to run a leak suspect report"
				placement="break"></image>
			<p>As a result an HTML report will be opened. It contains an overview
				of the heap dump and leak suspect info.
			</p>
			<image href="../mimes/leaksuspects.png"
				alt="screen shot of leak suspects" placement="break"></image>
			<p>This report will be stored together with the heap dump and can be
				displayed when you open the heap dump again.
			</p>
			<p>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 <xref href="../reference/tipsandtricks.dita#ref_tips/piechartlinks">Pie Chart Links</xref>
				for links from pie charts.
			</p>
			<image href="../mimes/leaksuspects1.png"
				alt="screen shot of leak suspect details showing links"
				placement="break"></image>
			<p>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.
			</p>
			<p>
				The starting point is the
				<xref href="../concepts/dominatortree.dita">dominator tree</xref>
				.
				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.
			</p>
			<p>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.
			</p>
			<p>
				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
				<term>accumulation point</term>
				.

				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.
			</p>
			<p>
				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.
			</p>
			<p>
				The
				<wintitle>Shortest Paths To the Accumulation Point</wintitle>
				shows a
				path from a
				<xref href="../concepts/gcroots.dita">garbage collection root</xref>
				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.
			</p>
			<p>
				The
				<wintitle>Accumulated Objects in Dominator Tree</wintitle>
				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
				<wintitle>Accumulated Objects by Class in Dominator Tree</wintitle>
				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.
				<wintitle>All Accumulated Objects by Class</wintitle>
				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.
			</p>
			<p>
				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
				<term>accumulation point</term>
				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
				<xref href="../concepts/reachability.dita">reachable</xref>
				and so alive.
				The standard options for the query ignore weak, soft, phantom and finalizer
				references when finding paths.
				In the report, the text <systemoutput>Most of these instances are referenced from one instance of</systemoutput>
				introduces the accumulation point.
			</p>
			<p>
				The query also attempts to find an <i>interesting</i>
				(not a standard Java class
				<codeph>java.</codeph> <codeph>javax.</codeph> <codeph>com.sun.</codeph> <codeph>jdk.</codeph>) 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 <systemoutput>The instance is referenced by</systemoutput> introduces this interesting object.
			</p>
			<p>
				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.
			</p>
			<p>
				If the leak suspect is a group of objects then
				the biggest few
				objects are shown by
				<wintitle>Biggest Instances (Overview)</wintitle> which is a pie chart and
				<wintitle>Biggest Instances</wintitle>
				which is a histogram.
				If there are many objects and none uses more than 1% of the leak
				then these is omitted.
			</p>
			<p>
				<wintitle>Suspect Objects by Class</wintitle>
				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.
			</p>
			<p>
				<wintitle>All Objects by Class Retained by Suspect Objects</wintitle>
				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.
			</p>
			<p>
				<wintitle>Common Path To the Accumulation Point</wintitle>
				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.
			</p>
			<p>
				<wintitle>Accumulated Objects in Dominator Tree</wintitle>
				<wintitle>Accumulated Objects by Class in Dominator Tree</wintitle>
				These show the accumulation point in the dominator tree, showing
				how it is retained, and the objects it retains.
			</p>
			<p>
				<wintitle>All Accumulated Objects by Class</wintitle>
				This shows the objects retained by the accumulation point.
			</p>
			<p>
				<wintitle>Reference Pattern </wintitle>
				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.
			</p>
			<p>
				<wintitle>Keywords </wintitle>
				The keyword section has words which could be useful to match this problem to previous problem instances.
			</p>

			<p>
				Learn more in this blog posting:
				<xref format="html" scope="external"
					href="https://memoryanalyzer.blogspot.com/2008/05/automated-heap-dump-analysis-finding.html">Automated Heap Dump Analysis: Finding Memory Leaks with One
					Click
				</xref>
				.
			</p>
			<note id="compare">
				There is also a leak suspects report made by comparing two
				snapshots.
				This is available via
				<menucascade>
					<uicontrol>Leak Identification</uicontrol>
					<uicontrol>Compare Snapshots Leak Report</uicontrol>
				</menucascade>
				or from the
				<wintitle>Overview</wintitle>
				panel as
				<cmdname>Leak Suspects by Snapshot Comparison</cmdname>
				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.
			</note>
		</context>
		<steps>
			<step>
				<cmd>
			In the toolbar select the drop-down menu
			<menucascade>
				<uicontrol>Run Expert System Test</uicontrol>
				<uicontrol>Leak Suspects</uicontrol>
			</menucascade>
			and generate the report.
				</cmd>
			</step>
		</steps>
		<result>
			The result is an HTML page giving information on of all the suspects.
			Various sections can be expanded to give more detail.
			If the HTML page is viewed inside of Eclipse Memory Analyzer then links allow
			further examination of objects.
		</result>
		<tasktroubleshooting>
			If the HTML page does not display properly inside Eclipse Memory Analyzer, consult
			<xref href="report.dita">Problems displaying reports</xref>.
		</tasktroubleshooting>
		<example>
			<p>
				Examples of summaries of leak suspects:
			</p>
				<lines><systemoutput><wintitle>Problem Suspect 1</wintitle>
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 "&lt;system class loader&gt;", which occupies 487,234,328 (28.60%) bytes.

Keywords
org.eclipse.mat.ui.compare.CompareBasketView$ComparePolicy
org.eclipse.mat.ui
java.lang.Object[]
				</systemoutput></lines>
				<lines><systemoutput><wintitle>Problem Suspect 2</wintitle>
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
				</systemoutput></lines>
				<lines><systemoutput><wintitle>Problem Suspect 3</wintitle>
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
				</systemoutput></lines>
				<lines><systemoutput><wintitle>Problem Suspect 4</wintitle>
The class "java.lang.ref.Finalizer", loaded by "&lt;system class loader&gt;",
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
				</systemoutput></lines>
				<lines><systemoutput><wintitle>Problem Suspect 5</wintitle>
19,414,929 instances of "int[]", 
loaded by "&lt;system class loader&gt;" occupy 716,412,176 (42.05%) bytes. 
These instances are referenced from one instance of "java.lang.Object[]", 
loaded by "&lt;system class loader&gt;", which occupies 77,659,616 (4.56%) bytes.

Keywords
int[]
java.lang.Object[]
				</systemoutput></lines>
				<lines><systemoutput><wintitle>Problem Suspect 6</wintitle>
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
				</systemoutput></lines>
				<lines><systemoutput><wintitle>Problem Suspect 7</wintitle>
1,868 instances of "java.lang.Class", 
loaded by "&lt;system class loader&gt;" occupy 1,000,176 (12.68%) bytes. 

Biggest instances:
 class sun.util.calendar.ZoneInfoFile @ 0xffe065a0 - 151,368 (1.92%) bytes. 

Keywords
java.lang.Class
				</systemoutput></lines>
				<lines><systemoutput><wintitle>Problem Suspect 8</wintitle>
One instance of "java.util.concurrent.ForkJoinTask[]" loaded by "&lt;system class loader&gt;" occupies 279.27 MB (40.12%) bytes. The instance is referenced by java.util.concurrent.ForkJoinWorkerThread @ 0xd53a1bf0 ForkJoinPool.commonPool-worker-0 , loaded by "&lt;system class loader&gt;". 

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 "&lt;system class loader&gt;", 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
				</systemoutput></lines>
				<lines><systemoutput><wintitle>Problem Suspect 9</wintitle>
1,417 instances of "org.eclipse.mat.hprof.SeekableStream$PosStream", loaded by "org.eclipse.mat.hprof" occupy 74,697,464 (31.80%) bytes. 

Most of these instances are referenced from one instance of "java.util.TreeMap$Entry", loaded by "&lt;system class loader&gt;", which occupies 56,560 (0.02%) bytes. The instance is referenced by "org.eclipse.mat.hprof.SeekableStream @ 0x6053cd130", loaded by "org.eclipse.mat.hprof". 

Keywords
org.eclipse.mat.hprof.SeekableStream$PosStream
org.eclipse.mat.hprof
java.util.TreeMap$Entry
org.eclipse.mat.hprof.SeekableStream
				</systemoutput></lines>
				<lines><systemoutput><wintitle>Problem Suspect 10</wintitle>
				84,857 instances of "org.eclipse.swt.widgets.TreeItem", loaded by "org.eclipse.swt" occupy 30,539,432 (13.00%) bytes. 

Most of these instances are referenced from one instance of "org.eclipse.swt.widgets.TreeItem[]", loaded by "org.eclipse.swt", which occupies 339,216 (0.14%) bytes. 

Thread "java.lang.Thread @ 0x604802e10 main" has a local variable or reference to "org.eclipse.swt.widgets.Shell @ 0x604e4d848" which is on the shortest path to "org.eclipse.swt.widgets.TreeItem[84800] @ 0x61bc96500". The thread java.lang.Thread @ 0x604802e10 main keeps local variables with total size 41,544 (0.02%) bytes.

Significant stack frames and local variables
	org.eclipse.mat.ui.internal.diagnostics.DiagnosticsWizardAction.run()V (DiagnosticsWizardAction.java:45)
		org.eclipse.swt.widgets.Shell @ 0x604e4d848 retains 2,616 (0.00%) bytes

The stacktrace of this Thread is available. See stacktrace. See stacktrace with involved local variables.

Keywords
org.eclipse.swt.widgets.TreeItem
org.eclipse.swt
org.eclipse.swt.widgets.TreeItem[]
org.eclipse.mat.ui.internal.diagnostics.DiagnosticsWizardAction.run()V
DiagnosticsWizardAction.java:45
				</systemoutput></lines>
		</example>
	</taskbody>
</task>