# Using HotSpot Serviceability Agent (SA)

### HSDB GUI

The top-level GUI program using the HotSpot Serviceability Agent APIs is 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.

### SA Modes

There are three modes for the SA debugger:

- attaching to a local process
- opening a core file
- attaching to a remote "debug server"

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.

### Command line HSDB

There is also a command line HSDB variant. It is launched using "jhsdb clhsdb". More details on the command line interface can be found in the "jhsdb" man page and also in:

- clhsdb.html

### Compilation Replay

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

### Debugging transported core dumps

When a core dump is moved from the machine where it was produced to a 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.

### SA Bugs

Not all of the possible states of target VMs have been tested (or 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.