IBM BS029ML - WebSphere Portal Server Self Help Manual page 176

Refer to the IBM Java SDK InfoCenter for more information about using the dbx utility, found
at:
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=/com.ibm.jav
a.doc.diagnostics.60/diag/problem_determination/i5os_dbx_sysdump.html
JVM hangs
Knowing what to do when WebSphere becomes unresponsive will greatly improve your ability
to move a problem to a successful resolution. For this reason, we consider the situation when
a WebSphere JVM appears to hang on the AIX platform. Over the next few subsections, we
will see how it is potentially possible to determine the cause of such a JVM hang.
Without necessarily knowing Java or the low-level specifics of the underlying AIX operating
system, you can get straight to work and put these techniques into practice should you
experience a hang.
Debugging hangs
If the JVM is hanging and the process is still present but is not responding, then the following
causes should be investigated:
The process has come to a complete halt because of a deadlock condition.
A lock (also referred to as a monitor) prevents more than one entity from accessing a
shared resource. Each object in Java has an associated lock (obtained by using a
synchronized block or method). In the case of the JVM, threads compete for various
resources in the JVM and locks on Java objects.
Example 5-1 was taken from a deadlock test program where two threads
"DeadLockThread 0" and "DeadLockThread 1" were unsuccessfully attempting to
synchronize on two java/lang/Integers.
You can see in Example 5-3 on page 166 that "DeadLockThread 1" has locked the object
instance java/lang/Integer@004B2290. The monitor has been created as a result of a
Java code fragment looking like "synchronize(count0)", and this monitor has
"DeadLockThread 1" waiting to get a lock on this same object instance (count0 from the
code fragment). Below the highlighted section is another monitor locked by
"DeadLockThread 0" that has "DeadLockThread 1" waiting.
This classic deadlock situation is caused by an error in application design; javadump is a
major tool in the detection of such events.
Example 5-1 Deadlock example
LOCKS subcomponent dump routine Monitor pool info:
Current total number of monitors: 2
Monitor Pool Dump (flat & inflated object-monitors):
sys_mon_t:0x00039B40 infl_mon_t: 0x00039B80:
java/lang/Integer@004B22A0/004B22AC: Flat locked by "DeadLockThread 1"
java/lang/Integer@004B2290/004B229C: Flat locked by "DeadLockThread 0"
JVM System Monitor Dump (registered monitors):
Deadlock detected !!!
Thread "DeadLockThread 1" (0x41DAB100)
is waiting for:
sys_mon_t:0x00039B98 infl_mon_t: 0x00039BD8:
java/lang/Integer@004B2290/004B229C:
162
IBM WebSphere Portal V6 Self Help Guide
(0x41DAB100), entry count 1
Waiting to enter:
"DeadLockThread 0" (0x41DAAD00)
Waiting to enter:
"DeadLockThread 1" (0x41DAB100)
Thread global lock (0x00034878): <unowned>
NLS hash table lock (0x00034928): <unowned>
portLibrary_j9sig_async_monitor lock (0x00034980): <unowned>
Hook Interface lock (0x000349D8): <unowned>
sys_mon_t:0x00039B98 infl_mon_t: 0x00039BD8:
(0x41DAAD00), entry count 1