WebSphere is often run on top of the IBM Java or IBM Semeru Runtimes JVM (both hereafter referred to as the J9 JVM). One of the biggest diagnostic features of the J9 JVM is the ability to cheaply gather a thread dump using the "SIGQUIT" signal to create a file with thread stacks, lock contention, and other information to help diagnose performance problems, hangs, high CPU, and other types of issues. On non-Windows operating systems, this is normally done by running the following command, replacing
with the process ID of Java:
kill -3 $PID
This is a wonderful, built-in feature; however, the J9 JVM also has other valuable diagnostic capabilities that are sometimes needed such as gathering heapdumps, core dumps, running external problems, and other -Xdump agents. Historically, there has only been this one signal to use so customers or support engineers might recommend changing the default behavior to produce something in addition to, or instead of, the thread dump. For example, one of the most common things is to request a heap dump or core dump using this signal.
The problem with overriding the default is that some of these other diagnostics are much more expensive to produce. So while this may be acceptable in certain situations, the lightweight diagnostics are no longer be available in other situations.
This situation is now improved by the introduction of a new signal that can be associated with -Xdump agents on non-Windows operating systems: the SIGUSR2 signal.
Starting with IBM Java 126.96.36.199 and Semeru v8.0.352 / 188.8.131.52 / 184.108.40.206, you may specify a JVM argument to tell the JVM what diagnostics to produce on this USR2 signal. For example, if you wanted to produce a core dump on this signal, you would specify:
Then this may be triggered with the following command, replacing
$PID with the process ID of Java:
kill -USR2 $PID
This is a powerful addition to the flexibility of the ways in which -Xdump agents can be exercised.