Diagnostic commands can also be invoked by overriding the default behavior of the SIGQUIT process signal. Recollect from Chapter 4 that the default behavior of a JVM receiving a SIGQUIT is to write a thread dump containing the current state of all the threads to the console. One way of sending a SIGQUIT signal to the JVM process is to press Ctrl + Break (Windows), or Ctrl + (Linux), in the shell where the Java process was started. On *NIX-systems, executing kill -3 <PID> or kill -QUIT <PID> from a shell is an alternative way of issuing a SIGQUIT to a process with a given ID.
To override the SIGQUIT behavior of JRockit with a custom command sequence; put the list of commands to be executed in a plain text file and name it ctrlhandler.act. The file needs to be placed into the lib folder of JRockit distribution or the current directory of the JVM process. The presence of a crtlhandler.act file overrides the behavior of the SIGQUIT signal and makes it execute your diagnostic commands instead of producing the normal thread stack dump. Following is an example of a ctrlhandler.act file:
version
print_threads
print_object_summary
A ctrlhandler.act file can be passed to JRCMD using the -f option. This option causes JRCMD to read the commands to execute from the ctrlhandler.act file.
Following is an example using the -f option with the ctrlhandler.act file from the previous example:
C:>jrcmd 7736 -f c: mpctrlhandler.act 7736: Oracle JRockit(R) build R28.0.0-670-129329-1.6.0_17 -20100219-2122-windows-ia32, compiled mode GC mode: Garbage collection optimized for short pausetimes, strategy: genconcon ===== FULL THREAD DUMP =============== Mon Mar 01 15:53:40 2010 Oracle JRockit(R) R28.0.0-670-129329-1.6.0_17-20100219-2122-windows-ia32 "Main Thread" id=1 idx=0x4 tid=7420 prio=6 alive, in native at org/eclipse/swt/internal/win32/OS.WaitMessage()Z(Native Method) at org/eclipse/swt/widgets/Display.sleep(Display.java:4220) at org/eclipse/ui/application/WorkbenchAdvisor.eventLoopIdle (WorkbenchAdviso r.java:364) at org/eclipse/ui/internal/Workbench.runEventLoop(Workbench.java:2385) at org/eclipse/ui/internal/Workbench.runUI(Workbench.java:2348) -- end of trace ===== END OF THREAD DUMP =============== --------- Detailed Heap Statistics: --------- 39.1% 8232k 140800 +8232k [C 13.5% 2840k 121192 +2840k java/lang/String 10.1% 2135k 2933 +2135k [Ljava/util/HashMap$Entry; 5.5% 1161k 49568 +1161k java/util/HashMap$Entry 4.2% 889k 8136 +889k java/lang/Class 4.1% 869k 18430 +869k [I 4.0% 841k 15322 +841k [Ljava/lang/Object; 2.0% 414k 299 +414k [B 1.3% 281k 12015 +281k java/util/ArrayList 1.2% 256k 4698 +256k org/eclipse/core/internal /registry/ReferenceMap$Soft Ref 1.1% 241k 1843 +241k [[C 0.6% 136k 2907 +136k java/util/HashMap 0.6% 130k 275 +130k [Ljava/util/Hashtable$Entry; 0.6% 116k 2407 +116k [Ljava/lang/String; 21054kB total --- --------- End of Detailed Heap Statistics ---
Not all the diagnostic commands are available by default. There are, for example, commands to force JRockit to crash (and dump core) and for instantiating any class in the system implementing the java.lang.Runnable interface and then calling the start method of the instances. For added security, these kinds of commands are disabled by default and must be enabled by setting command-specific system properties in JRockit on startup.
A command can be enabled by specifying the system property jrockit.ctrlbreak.enable<command>=[true|false]. For example:
-Djrockit.ctrlbreak.enableforce_crash=true
-Djrockit.ctrlbreak.enablerun_class=true