Google Git
Sign in
eclipse / mat / org.eclipse.mat / 8e7d52309c64ada60af70249dc10ceec713d75d2 / . / plugins / org.eclipse.mat.ui.help / tasks / acquiringheapdump.dita
blob: 729bdc2d22d5577eddaf885c591a0d213a3a20c9 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright (c) 2008, 2018 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 v1.0
which accompanies this distribution, and is available at
http://www.eclipse.org/legal/epl-v10.html
Contributors:
SAP AG - initial documentation
IBM Corporation - documentation on IBM specific dumps
-->
<!DOCTYPE task PUBLIC "-//OASIS//DTD DITA Task//EN" "task.dtd" >
<task id="task_acquiringheapdump" xml:lang="en-us">
<title>Acquiring Heap Dumps</title>
<prolog>
<copyright>
<copyryear year=""></copyryear>
<copyrholder>
Copyright (c) 2008, 2018 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 v1.0
which accompanies this distribution, and is available at
http://www.eclipse.org/legal/epl-v10.html
</copyrholder>
</copyright>
</prolog>
<taskbody>
<context>
<!-- ***************************************************************
* HPROF dumps
****************************************************************** -->
<p><b>HPROF Binary Heap Dumps</b></p>
<p><i>Get Heap Dump on an OutOfMemoryError</i></p>
<p> One can get a HPROF binary heap dump on an OutOfMemoryError for Sun JVM
(1.4.2_12 or higher and 1.5.0_07 or higher), Oracle JVMs,
OpenJDK JVMs,
HP-UX JVM (1.4.2_11 or
higher) and SAP JVM (since 1.5.0) by setting the following JVM
parameter:</p>
<p>
<codeblock>-XX:+HeapDumpOnOutOfMemoryError</codeblock>
</p>
<p>The heap dump is written to the work directory.</p>
<p><i>Interactively Trigger a Heap Dump</i></p>
<p> To get heap dump on demand one can add the following parameter to the JVM
and press CTRL + BREAK in the preferred moment:</p>
<p>
<codeblock>-XX:+HeapDumpOnCtrlBreak</codeblock>
</p>
<p><i>HPROF agent</i></p>
<p>To use the HPROF agent to generate a dump on the end of execution, or on SIGQUIT signal use the following
JVM parameter:</p>
<p>
<codeblock>-agentlib:hprof=heap=dump,format=b</codeblock>
</p>
<p> Alternatively, other tools can be used to acquire a heap dump:
</p>
<ul>
<li>
<cmdname>jmap -dump:format=b,file=&lt;filename.hprof&gt; &lt;pid&gt;</cmdname>
</li>
<li>JConsole (see sample usage in <xref href="../gettingstarted/basictutorial.dita">Basic Tutorial</xref>)</li>
<li>Memory Analyzer (see bottom of page)</li>
</ul>
<!-- ***************************************************************
* IBM dumps
****************************************************************** -->
<p><b>System Dumps and Heap Dumps from IBM Virtual Machines </b></p>
<p>
Memory Analyzer can also read memory-related information from IBM system
dumps and from Portable Heap Dump (PHD) files. For this purpose one just
has to install the IBM DTFJ feature into Memory Analyzer.
Follow the <xref href="installDTFJ.dita">IBM DTFJ feature installation instructions</xref>. Once the DTFJ
feature is successfully installed, then
<menucascade>
<uicontrol>File</uicontrol>
<uicontrol>Open Heap Dump</uicontrol>
</menucascade>
menu should also offer the following options for the file types:
<ul>
<li>All known formats</li>
<li>HPROF binary heap dumps</li>
<li>IBM 1.4.2 SDFF<fn>IBM DTFJ feature versions >= 1.12.29003.201808011034 do not have this option</fn></li>
<li>IBM Javadumps</li>
<li>IBM SDK for Java (J9) system dumps</li>
<li>IBM SDK for Java Portable Heap Dumps</li>
</ul>
</p>
<p>
For a comparison of dump types, see <xref format="html" href="http://www.ibm.com/developerworks/library/j-memoryanalyzer/#table1">Debugging from dumps</xref>.
System dumps are simply operating system core dumps; therefore, they are a superset of portable heap dumps.
System dumps are far superior than PHDs, particularly for more accurate GC roots, thread-based analysis, and unlike PHDs,
system dumps contain memory contents like HPROFs.
</p>
<p>
Older versions of IBM Java (e.g. &lt; 5.0SR12, &lt; 6.0SR9) require running jextract on the operating system core dump
which produced a zip file that contained the core dump, XML or SDFF file, and shared libraries. The IBM DTFJ feature
still supports reading these jextracted zips although IBM DTFJ feature version 1.12.29003.201808011034 and later cannot read IBM Java 1.4.2 SDFF files, so MAT cannot read them either.
Dumps from newer versions of IBM Java do not require jextract for use in
MAT since DTFJ is able to directly read each supported operating system's core dump format.
Simply ensure that the operating system core dump file ends with the <b>.dmp</b> suffix for visibility in the MAT Open Heap Dump selection.
It is also common to zip core dumps because they are so large and compress very well. If a core dump is compressed with <b>.zip</b>,
the IBM DTFJ feature in MAT is able to decompress the ZIP file and read the core from inside (just like a jextracted zip).
The only significant downsides to system dumps over PHDs is that they are much larger, they usually take longer to produce,
they may be useless if they are manually taken in the middle of an exclusive event that manipulates the underlying Java heap
such as a garbage collection, and they sometimes require operating system configuration (
<xref format="html" href="http://www.ibm.com/support/knowledgecenter/SSYKE2_7.1.0/com.ibm.java.lnx.71.doc/diag/problem_determination/linux_setup.html">Linux</xref>,
<xref format="html" href="http://www.ibm.com/support/knowledgecenter/SSYKE2_7.1.0/com.ibm.java.aix.71.doc/diag/problem_determination/aix_setup_full_core.html">AIX</xref>)
to ensure non-truncation.
</p>
<p>
In recent versions of IBM Java (&gt; 6.0.1), by default, when an OutOfMemoryError is thrown, IBM Java produces a system dump, PHD,
javacore, and Snap file on the first occurrence for that process (although often the core dump is suppressed by the default 0
core ulimit on operating systems such as Linux). For the next three occurrences, it produces only a PHD, javacore, and Snap.
If you only plan to use system dumps, and you've configured your operating system correctly as per the links above (particularly
core and file ulimits), then you may disable PHD generation with -Xdump:heap:none. For versions of IBM Java older than 6.0.1,
you may switch from PHDs to system dumps using
<codeblock>-Xdump:system:events=systhrow,filter=java/lang/OutOfMemoryError,request=exclusive+prepwalk -Xdump:heap:none</codeblock>
</p>
<p>
In addition to an OutOfMemoryError, system dumps may be produced using operating system tools (e.g. gcore in gdb for Linux,
gencore for AIX, Task Manager for Windows, SVCDUMP for z/OS, etc.), using the
<xref format="html" href="https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.api.80.doc/com.ibm.jvm.ras/index.html">IBM Java APIs</xref>,
using the various options of <xref format="html" href="http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.lnx.80.doc/diag/tools/dump_agents.html">-Xdump</xref>,
using <xref format="html" href="https://www.ibm.com/developerworks/community/groups/service/html/communityview?communityUuid=7d3dc078-131f-404c-8b4d-68b3b9ddd07a">Java Surgery</xref>,
and more.
</p>
<p>
Versions of IBM Java older than IBM JDK 1.4.2 SR12, 5.0 SR8a and 6.0 SR2 are known to produce inaccurate GC root information.
</p>
<!-- ***************************************************************
* Acquire from Memory Analyzer
****************************************************************** -->
<p><b>Acquire Heap Dump from Memory Analyzer</b></p>
<p>
If the Java process from which the heap dump is to be acquired is on the
same machine as the Memory Analyzer, it is possible to acquire a heap dump
directly from the Memory Analyzer. Dumps acquired this way are directly
parsed and opened in the tool.
</p>
<p>Acquiring the heap dump is VM specific. Memory Analyzer comes with
several so called heap dump providers - for Oracle and Sun based VMs
(needs a Oracle or Sun JDK
with jmap) and for IBM VMs (needs an IBM JDK or JRE).
Also extension points
are provided for adopters to plug-in their own heap dump providers.
</p>
<p>
To trigger a heap dump from Memory Analyzer open the
<menucascade>
<uicontrol>File</uicontrol>
<uicontrol>Acquire Heap Dump...</uicontrol>
</menucascade>
menu item.
</p>
<p>Depending on the concrete execution environment the pre-installed
heap dump
providers may work with their default settings and in this case a list of
running Java processes should appear:
To make selection easier,
the order of the Java processes can be altered by clicking on the column titles
for <uicontrol>pid</uicontrol> or <uicontrol>Heap Dump Provider</uicontrol>.
</p>
<image href="../mimes/acquire.png">
<alt>Select a process to be dumped</alt>
</image>
<p>
One can now select from which process a heap dump should be acquired, provide
a preferred
location for the heap dump and press
<uicontrol>Finish</uicontrol>
to acquire the dump. Some of the heap
dump providers may allow (or require) additional parameters (e.g. type of
the heap dump) to be set. This can be done by using
<menucascade>
<uicontrol>Next</uicontrol>
</menucascade>
button to get to the
<wintitle>Configuring Heap Dump Provider Arguments</wintitle>
page of the wizard.
</p>
<p>
<i>Configuring the Heap Dump Providers</i>
</p>
<p>
If the process list is empty try to configure the available heap dump
providers. To do this
press
<uicontrol>Configure...</uicontrol>
, select a matching provider from the list and click on it.
You can see
then what are the required settings and specify them.
<menucascade>
<uicontrol>Next</uicontrol>
</menucascade>
will then apply any changed settings, and
refresh the JVM list if any
settings have been changed.
<menucascade>
<uicontrol>Prev</uicontrol>
</menucascade>
will return to the
current JVM list without applying any changed
settings. To then apply the
changed settings
reenter and exit the
<wintitle>Configure Heap Dump Providers...</wintitle>
page as follows:
<menucascade>
<uicontrol>Configure...</uicontrol>
<uicontrol>Next</uicontrol>
</menucascade>
</p>
<p>
If a process is selected before pressing
<uicontrol>Configure...</uicontrol>
then the corresponding
dump provider will be selected on entering the
<wintitle>Configure Heap Dump Providers...</wintitle>
page.
</p>
<p>
<dl>
<dlentry>
<dt id="1">HPROF jmp dump provider</dt>
<dd>
This provider uses the
<cmdname>jps</cmdname>
command supplied with an Oracle or OpenJDK based JDK to list the
running JVMs on the system. The provider then uses the
<cmdname>jmap</cmdname>
command to get the chosen
JVM to generate an HPROF dump. This
provider requires a JDK (Java
development kit), not a JRE
(Java
runtime environment) for those two commands. IBM JDKs do not
have
the
<cmdname>jps</cmdname>
or
<cmdname>jmap</cmdname>
commands. The commands on an OpenJ9 JDK may not work well enough
for
this provider to work with those JVMs.
</dd>
</dlentry>
<dlentry id="2">
<dt>Attach API</dt>
<dd>
This uses the
<xref
href="https://docs.oracle.com/javase/8/docs/jdk/api/attach/spec/com/sun/tools/attach/package-summary.html"
format="html">
<apiname>com.sun.tools.attach</apiname>
</xref>
or
<xref
href="https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.lnx.80.doc/user/attachapi.html"
format="html">
<apiname>com.ibm.tools.attach</apiname>
</xref>
APIs to list the JVMs and then to attach to the chosen JVM to
generate a
dump.
The Attach API is supplied as part of IBM JDKs and
JREs, but is only
supplied as part of Oracle or OpenJDK JDKs
in
<codeph>tools.jar</codeph>
and not as part of JREs. Therefore if Memory Analyzer is run with
an Oracle JRE
then this dump provider will not be available.
The
<apiname>com.sun.tools.attach</apiname>
API is available on Oracle and OpenJDK JDKs, on OpenJ9 JDKs and
JREs
and IBM JDKs and JREs version Java 8 SR5 or later.
The
<apiname>com.ibm.tools.attach</apiname>
API is available on earlier IBM JDKs and JREs.
The Attach API dump
provider automatically uses whichever Attach API
is available,
and
loads
<codeph>tools.jar</codeph>
if required.
The Attach API with Java 9 or later does not permit a Java process
to connect to itself, so MemoryAnalyzer cannot generate a dump of
itself using the Attach API dump provider. Use another dump provider instead.
</dd>
</dlentry>
<dlentry id="3">
<dt>Attach API with helper JVM</dt>
<dd>
If Memory Analyzer is run with an Oracle JRE then this dump
provider can be used with an Oracle JDK by providing a path
to a
<cmdname>java</cmdname>
executable. The dump provider will load the
<codeph>tools.jar</codeph>
if required.
so that the
<apiname>com.sun.tools.attach</apiname>
API
is acessible. This provider can also be used to list JVMs
of a
different type from the JVM used to run Memory Analyzer.
For example
dumps from IBM JVMs can be generated by specifying a
path to
an IBM
JVM
<cmdname>java</cmdname>
command even when Memory Analyzer is run with an Oracle JVM.
</dd>
</dlentry>
</dl>
</p>
<p>
<i>Options</i>
</p>
<p>
<dl>
<dlhead>
<dthd>Dump Type</dthd>
</dlhead>
<dlentry>
<dt>System</dt>
<dd>
These process core dumps are generated using the
<apiname>com.ibm.jvm.Dump.SystemDump()</apiname>
method
called by an agent library generated and loaded into the
target JVM by
Memory Analyzer.
These dumps can be generated by IBM
and
OpenJ9 JVMs.
</dd>
</dlentry>
<dlentry>
<dt>Heap</dt>
<dd>
These Portable Heap Dumps are generated using the
<apiname>com.ibm.jvm.Dump.HeapDump()</apiname>
method
called by an agent library generated and loaded into the
target JVM by
Memory Analyzer.
These dumps can be generated by IBM
and
OpenJ9 JVMs.
</dd>
</dlentry>
<dlentry>
<dt>Java</dt>
<dd>
These Javacore dumps are generated using the
<apiname>com.ibm.jvm.Dump.JavaDump()</apiname>
method
called by an agent library generated and loaded into the
target JVM by
Memory Analyzer.
These dumps can be generated by IBM
and OpenJ9
JVMs.
</dd>
</dlentry>
<dlentry>
<dt>HPROF</dt>
<dd>
These HPROF dumps are generated using the
<apiname>com.sun.management:type=HotSpotDiagnostic</apiname>
MXBean called in an agent library generated and loaded into the
target JVM by Memory Analyzer.
These dumps can be generated by
Oracle and
OpenJDK JVMs.
</dd>
</dlentry>
</dl>
<dl>
<dlhead>
<dthd>Other options</dthd>
</dlhead>
<dlentry>
<dt>compress</dt>
<dd>
System dumps can be processed using
<xref
href="https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.lnx.80.doc/diag/tools/dump_viewer_dtfjview/jextract.html"
format="html">
<cmdname>jextract</cmdname>
</xref>
which compressed the dump and
also adds extra system information so
that the dump could be moved to
another machine.
Portable Heap Dump
(PHD) files generated with the Heap option can be compressed using
the gzip compressor
to reduce
the file size.
</dd>
</dlentry>
<dlentry>
<dt>live</dt>
<dd>On IBM JVMs this forces a garbage collection before a dump is
taken. This could affect
the performance of the program running on
the target JVM,
but may reduce the size of PHD Heap dumps.
On Oracle and
OpenJDK JVMs this
dumps only live objects into the HPROF file and
should reduce its
size.
By default,
Memory Analyzer removes the
non-live objects from
the dump as it indexes
the dump and builds the
snapshot, and puts
information about those objects
in the unreachable
objects histogram.
If this histogram is used or the 'keep
unreachable objects'
option is
set then the live option should not be
set as it will remove
required information.</dd>
</dlentry>
<dlentry>
<dt>listattach</dt>
<dd>This is used when listing JVMs using the Attach API. The dump
provider then attaches to each
running JVM in the list and extracts
more information to give a better
description. This can take a
little longer, so if the list operation
is cancelled then this
option is disabled so the next listing
will be faster. The option
can be reenabled if required.</dd>
</dlentry>
<dlentry>
<dt>dumpdir</dt>
<dd>
IBM JVMs produce dumps in a directory specified by the target JVM,
not by Memory Analyzer.
Memory Analyzer needs to find the dump it
caused to be generated, and
looks in the
target JVM
<codeph>user.dir</codeph>
for the dump files. If this is not the right place then Memory
Analyzer will not find the
gnerated dump, so the user would have to
find it manually afterwards. If the
user knows
where the target JVM
will produce dumps then it can be entered using
this option.
</dd>
</dlentry>
<dlentry>
<dt>dumptemplate</dt>
<dd>
This gives an example file name to be used for the dump. The time
and date is inserted into the name using
substitution variable 0,
for example
<codeph>{0,date,yyyyMMdd.HHmmss}</codeph>
.
The process identifier is inserted using subsitution variable 1,
for
example
<codeph>{1,number,0}</codeph>
.
The instance number, used to make the dump file unique, is
inserted
using subsitution variable 2, for example
<codeph>{2,number,0000}</codeph>
. The extra 0000 is a standard MessageFormat modifier giving the
minimum
number of digits to use.
</dd>
</dlentry>
</dl>
</p>
<p><b>Multiple snapshots in one heap dump</b></p>
<p>
Occasionally heap dumps files can be generated which contain multiple heap dumps snapshots.
If an HPROF dump is generated using
<codeblock>-agentlib:hprof=heap=dump,format=b</codeblock>
then if a heap dump is triggered multiple times all the heap dumps will be written to one file.
An IBM z/OS system dump can contain data from multiple address spaces and processes.
It is therefore possible that the dump file contains heap dump snapshots from multiple Java runtimes.
</p>
<p>
Memory Analyzer 1.2 and earlier handled this situation by choosing the first heap dump snapshot found unless another
was selected via an environment variable or MAT DTFJ configuration option.
</p>
<p>
Memory Analyzer 1.3 handles this situation by detecting the multiple dumps, then presenting a dialog
for the user to select the required snapshot.
</p>
<image href="../mimes/multiple_snapshots.png">
<alt>Choose a snapshot to be analyzed</alt>
</image>
<p>
The index files generated have a component in the file name from the snapshot identifier, so the index
files from each snapshot can be distinguished.
This means that multiple snapshots from one heap dump file can be examined in Memory Analyzer
simultaneously.
The heap dump history for the file remembers the last snapshot selected for that file, though when
the snapshot is reopened via the history the index file is also shown in the history.
To open another snapshot in the dump, close the first snapshot, then reopen the heap dump file using the File menu and
another snapshot can be chosen to be parsed.
The first snapshot can then be reopened using the index file in the history, and both snapshots can
be viewed at once.
</p>
<p>
<b>Summary</b>
</p>
<p>The following table shows the availability of VM options and tools
on the various platforms:</p>
<table>
<tgroup cols="7">
<colspec colname="COLSPEC1" colwidth="2*" />
<colspec colname="COLSPEC2" colwidth="4*" />
<colspec colname="COLSPEC3" colwidth="4*" />
<colspec colname="COLSPEC4" colwidth="4*" />
<colspec colname="COLSPEC5" colwidth="2*" />
<colspec colname="COLSPEC6" colwidth="4*" />
<colspec colname="COLSPEC7" colwidth="2*" />
<colspec colname="COLSPEC8" colwidth="2*" />
<colspec colname="COLSPEC9" colwidth="4*" />
<colspec colname="COLSPEC10" colwidth="4*" />
<thead>
<row>
<entry colname="COLSPEC1" valign="top">Vendor</entry>
<entry colname="COLSPEC2" valign="top">Release</entry>
<entry namest="COLSPEC3" nameend="COLSPEC5" valign="top">VM
Parameter</entry>
<entry namest="COLSPEC6" nameend="COLSPEC7" valign="top">Sun
Tools</entry>
<entry colname="COLSPEC8" valign="top">SAP Tool</entry>
<entry colname="COLSPEC9" valign="top">Attach</entry>
<entry colname="COLSPEC10" valign="top">MAT</entry>
</row>
</thead>
<tbody>
<row>
<entry />
<entry />
<entry colname="COLSPEC3">On out of memory</entry>
<entry colname="COLSPEC4">On Ctrl+Break</entry>
<entry>Agent</entry>
<entry>JMap</entry>
<entry>JConsole</entry>
<entry>JVMMon</entry>
<entry>API</entry>
<entry>acquire heap dump</entry>
</row>
<row>
<entry morerows="2">Sun, HP</entry>
<entry>1.4.2_12</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry />
<entry />
<entry />
<entry />
<entry>No</entry>
</row>
<row>
<entry>1.5.0_07</entry>
<entry>Yes</entry>
<entry>Yes (Since 1.5.0_15)</entry>
<entry>Yes</entry>
<entry>Yes (Only Solaris and Linux)</entry>
<entry />
<entry />
<entry>com.sun.tools.attach</entry>
<entry>Yes (Only Solaris and Linux)</entry>
</row>
<row>
<entry>1.6.0_00</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry></entry>
<entry>com.sun.tools.attach</entry>
<entry>Yes</entry>
</row>
<row>
<entry morerows="1">Oracle, OpenJDK, HP</entry>
<entry>1.7.0</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry></entry>
<entry>com.sun.tools.attach</entry>
<entry>Yes</entry>
</row>
<row>
<entry>1.8.0</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry></entry>
<entry>com.sun.tools.attach</entry>
<entry>Yes</entry>
</row>
<row>
<entry>SAP</entry>
<entry>Any 1.5.0</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes (Only Solaris and Linux)</entry>
<entry />
<entry>Yes</entry>
<entry></entry>
<entry />
</row>
<row>
<entry morerows="6">IBM</entry>
<entry>1.4.2 SR12</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry></entry>
<entry>No</entry>
</row>
<row>
<entry>1.5.0 SR8a</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>com.ibm.tools.attach</entry>
<entry>No</entry>
</row>
<row>
<entry>1.6.0 SR2</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>com.ibm.tools.attach</entry>
<entry>No</entry>
</row>
<row>
<entry>1.6.0 SR6</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>com.ibm.tools.attach</entry>
<entry>Yes</entry>
</row>
<row>
<entry>1.7.0</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>com.ibm.tools.attach</entry>
<entry>Yes</entry>
</row>
<row>
<entry>1.8.0</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>com.ibm.tools.attach</entry>
<entry>Yes</entry>
</row>
<row>
<entry>1.8.0 SR5</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>No</entry>
<entry>com.sun.tools.attach</entry>
<entry>Yes</entry>
</row>
<row>
<entry>OpenJ9</entry>
<entry>1.8.0</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>Yes (PHD only)</entry>
<entry>No</entry>
<entry>com.sun.tools.attach</entry>
<entry>Yes</entry>
</row>
</tbody>
</tgroup>
</table>
</context>
</taskbody>
</task>