2N/AUsing HotSpot Serviceability Agent (SA)
2N/A<
h1>Using HotSpot Serviceability Agent (SA)</
h1>
2N/AThe top-level GUI program using the HotSpot Serviceability Agent APIs is
2N/Acalled <
b>HSDB</
b>, the "HotSpot Debugger". To run it, type "
hsdbproc.sh"
2N/AThere are three modes for the SA debugger:
2N/A<
li>attaching to a local process,
2N/A<
li>opening a core file, and
2N/A<
li>attaching to a remote "debug server".
2N/AThe remote case requires two programs to be running on the remote machine:
2N/Arun this in the background) and the debug server (see the script
2N/Athe process ID or the executable and core file names to allow remote debugging
2N/A<
h3>Command line HSDB</
h3>
2N/Aor 64-bit variants). There is also a JavaScript based command line interface
2N/Acommand line interfaces can be found in
2N/A<
h3>Other command line tools</
h3>
2N/AThe following table lists all SA command line tools. <xxx>
windbg.bat 2N/Afiles are for Windows. .sh files are for Solaris. <xxx>
64.sh are for
dumps name and value of all -XX JVM command line arguments passed
<
a name="dumpsysprops"></
a>
This prints name and value of Java level System properties.
Dumps heap in a file in hprof binary format.
Prints summary information on Java heap.
This can retrieve .class files from the debuggee.
set the environment variable <
b>JCORE_PACKAGES</
b> to comman separated list of
packages whose classes have to be retrieved from the core file.
used to get java stack trace for all java threads.
used to get object histogram of java heap.
To gather statistics on perm. generation.
<
a name="mixed_pstack"></
a>
This is cross platform mixed mode pstack utility. This works on any (non-java as well) process, core dump. For java process and core dumps, this prints both java and C/C++ frames.
This is cross platform Solaris pmap-like utility.
This is command line SOQL - Simple Object Query Language tool.
SOQL is SQL-like query language to query Java heap.
These scripts are used to run SA remotely.
<
h3>Debugging transported core dumps</
h3>
When a core dump is moved from the machine where it was produced to a
difference machine, it may not always be possible for SA to debug the same.
More info. on debugging on transported core dumps is in
Not all of the possible states of target VMs have been tested (or
supportable) with SA. For example, the SA will probably not work at all
if it freezes the target VM during certain phases of GC. When filing bugs
a pointer to a core file (see gcore(1)) which the SA can not handle well