plugins/org.eclipse.mat.ui.help/tasks/runningleaksuspectreport.dita - mat/org.eclipse.mat - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!--
     Copyright (c) 2008, 2021 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, 2021 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.
 				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.
 			</p>
 			<p>
 				The
 				<wintitle>Shortest Paths To the Accumulation Point</wintitle>
 				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.
 			</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.
 				<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
 				the biggest few
 				objects are shown by
 				<wintitle>Biggest Instances</wintitle>
 				.
 				If there are many objects and none uses more than 1% of the leak
 				then this is omitted.
 			</p>
 			<p>
 				If the leak suspect is a group of objects then the query
 				attempts to
 				find an
 				<i>interesting</i>
 				(not a standard Java class
 				<codeph>java.</codeph>
 				) 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.
 				<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.
 				If the root of this path is a thread then some
 				interesting thread
 				related information is also extracted.
 			</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>
 			<p 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.
 			</p>
 		</context>
 		<result>
 			<p>
 				Examples of summaries of leak suspects:
 				<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>
 			</p>
 		</result>
 	</taskbody>
 </task>
	<?xml version="1.0" encoding="UTF-8"?>
	<!--
	Copyright (c) 2008, 2021 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, 2021 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.
	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.
	</p>
	<p>
	The
	<wintitle>Shortest Paths To the Accumulation Point</wintitle>
	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.
	</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.
	<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
	the biggest few
	objects are shown by
	<wintitle>Biggest Instances</wintitle>
	.
	If there are many objects and none uses more than 1% of the leak
	then this is omitted.
	</p>
	<p>
	If the leak suspect is a group of objects then the query
	attempts to
	find an
	<i>interesting</i>
	(not a standard Java class
	<codeph>java.</codeph>
	) 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.
	<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.
	If the root of this path is a thread then some
	interesting thread
	related information is also extracted.
	</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>
	<p 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.
	</p>
	</context>
	<result>
	<p>
	Examples of summaries of leak suspects:
	<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 "<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[]
	</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 "<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
	</systemoutput></lines>
	<lines><systemoutput><wintitle>Problem Suspect 5</wintitle>
	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[]
	</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 "<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
	</systemoutput></lines>
	<lines><systemoutput><wintitle>Problem Suspect 8</wintitle>
	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
	</systemoutput></lines>
	</p>
	</result>
	</taskbody>
	</task>