diff --git a/src/jdk.hotspot.agent/doc/index.html b/src/jdk.hotspot.agent/doc/index.html index 24f37130e6e..9a67ad1bf77 100644 --- a/src/jdk.hotspot.agent/doc/index.html +++ b/src/jdk.hotspot.agent/doc/index.html @@ -10,220 +10,55 @@ Using HotSpot Serviceability Agent (SA)
The top-level GUI program using the HotSpot Serviceability Agent APIs is -called HSDB, the "HotSpot Debugger". To run it, type "hsdbproc.sh" -or "hsdbwindbg.bat" or 64-bit variants (on Unix, Windows platforms -respectively). More info. on HSDB GUI are in hsdb.html. +called HSDB, the "HotSpot Debugger". To run it, type "jhsdb hsdb". +More info on HSDB GUI are in hsdb.html. Also +see the "jhsdb" man page.
-There are three modes for the SA debugger: +There are three modes for the SA debugger:
-The remote case requires two programs to be running on the remote machine: -the rmiregistry (see the script "start-rmiregistry.sh" in this directory; -run this in the background) and the debug server (see the script -"start-debug-server-proc.sh"), in that order. start-rmiregistry.sh takes no -arguments; start-debug-server-proc.sh (or -windbg.bat) takes as argument -the process ID or the executable and core file names to allow remote debugging -of. +The remote case requires running the debug server on the remote machine. This +is done by running "jhsdb debugd", and also adding arguments specifying the core +file or process to debug. Once this is done you can connect remotely +to the debug server by running various other "jhsdb" subcommands, and specifying +which debug server to connect to. See the "jhsdb" man page for details.
-There is also a command line HSDB variant. More details on the command line interface can be found in: -
-The following table lists all SA command line tools. <xxx>windbg.bat -files are for Windows. .sh files are for Solaris. <xxx>64.sh are for -64 bit debugees. -
- --When a java process crashes in compiled method, usually a core file is saved. -The C2 replay function can reproduce the compiling process in the core. -c2replay.html +When a java process crashes in a compiled method, usually a core file is saved. +The compiler replay function can reproduce the compiling process in the core. +See cireplay.html
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 +different machine, it may not always be possible for SA to debug it. +More info on debugging on transported core dumps is in transported_core.html.
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 +are 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 is best.