Feature

This article is meant to bring you up to speed on Java dumps and their debugging purposes quickly. It assumes that you’re familiar with basic Java, the Java Virtual Machine (JVM), and threading concepts. Some information about Java dumps and their contents is intentionally omitted from the discussion to simplify things since it’s not relevant to the type of problem determination discussed here.

Basics
A Java dump, also known as a Java core, Java thread dump, or a thread dump is a file that contains the following sections:

• All of the threads that run on a Java Virtual Machine (JVM).
• All of the monitors on a JVM.
• Some useful information about the system that the JVM runs under.

In this article we’ll refer to this collection of threads, monitors, and miscellaneous information as a Java dump. We’ll focus mainly on the Java dumps from the IBM Java Development Kit (JDK) 1.3.1 and JDK 1.4.1. Although the formats of Java dumps can vary slightly with the different versions of the JDK depending on the vendor and platforms, you’ll be able to apply most of the concepts discussed here in interpreting Java dumps from WebSphere Application Server V4.x, V5.0.x, and V5.1.x.

Format – Dump Routines
The following picture is a representation of a Java dump broken into subcomponents:

The following list describes the subcomponents found in Figure 1:

• Tags – The tags are located on the left side of the Java dump. They help you visualize the subcomponent represented by the data on the right side of the file. For example, 2LKINFLATEDMON is a tag for the LK subcomponent.
• TITLE – Describes what causes the JVM to produce the Java dump file. The TITLE subcomponent contains the date and time of occurrence and the location in your file system. You can use this information to determine if the Java dump was created by a user or was system-generated.
• XHPI – When available, this dump routine describes the operating environment, memory information, user limits, and other operating system related details.
• CI – Use this section to identify the JVM build, the class path that the JVM uses, the JVM system property variables, and other system information related to the JVM.
• LK – Provides information for all of the monitors in the JVM. You can use this section to analyze how resources are used by various threads.
• XM – This section provides a detailed list of all the threads and their states. It also provides the current stack trace for each thread listed. You can use the stack trace to relate the current activity of thread with the source code.
• CL – Lists all of the classes and class loaders that load at run time. If you know the classes or libraries required by your application, you can cross-reference the information against the list of classes provided in this section.
• JVMMI DC DG ST XE – See the Appendix for more details on these sections.

Operating System Differences
Java dumps vary from one operating system to another. Although the variation doesn’t differ greatly, most of the differences are found in the operating-specific information that the Java dump routines collect. One of these differences is how the environment variables that are set on a specific operating system in a Unix system, for example, are handled differently than Windows environment variables. These variables will display differently when you collect a Java dump on a Unix system and compare it to one collected on a Windows system.

Java Service Release Differences
Between each Java service release, the Java dump routine is enhanced to provide the most information possible when diagnosing problems.
For this reason, you’ll notice that a Java dump from one service release of the JDK to another is formatted differently in terms of tabs or spaces or additional information. For example, if you compare JDK 1.2.x Java dumps to JDK 1.3.x Java dumps, you’ll notice that the structure of the two documents is very different. Some data that’s found on the JDK 1.2.x Java dump is rearranged in the JDK 1.3.x Java dumps, such as the XM dump and LK dump routine locations.

Java Dump – Thread & Monitor Analysis
The following is an example of a thread stack trace in the XM dump routine:

3XMTHREADINFO “Thread-6” (TID:0x181D6A0, sys_thread_

  t:0x133AA648, state:R, native ID:0x948) prio=5

4XESTACKTRACE at java.net.PlainSocketImpl.

  socketAccept(Native Method)

4XESTACKTRACE at java.net.PlainSocketImpl.

  accept(PlainSocketImpl.java:446)

4XESTACKTRACE at java.net.ServerSocket.

  implAccept(ServerSocket.java:264)

4XESTACKTRACE at java.net.ServerSocket.

  accept(ServerSocket.java:243)

4XESTACKTRACE at com.ibm.disthub.impl.multi.server.

  SSConnMgr.threadMain(SSConnMgr.java:251)

4XESTACKTRACE at com.ibm.disthub.impl.client.

  DebugThread.run(DebugThread.java:66)

Example 1 – This is an example of a Java thread’s stack trace in the XM Dump Routine The first line of the previous example indicates that there’s a thread named Thread-6 that’s in a runnable state as indicated by the “state:R” parameter. This means that Thread-6 is either running or ready to run. Like all threads, Thread-6 has two primary identifiers: TID and sys_thread_t. For Thread-6, the values include 0x181D6A0 and 0x133AA648 respectively. You can cross-reference these values with the monitor data in the LK dump routine to detect deadlocks and identify problematic threads.

The remaining lines of text, identified by the “4XESTACKTRACE” tag, indicate the sequence of methods performed by the thread when the Java dump occurred. It is like a standard Java stack trace where the beginning of the code execution is read from the bottom to the top.

Just In Time (JIT) compiling is enabled when line numbers are replaced by the keywords “Compiled Code” in a stack trace as shown in Example 2. Disable JIT compiling to display the line numbers. Refer to the WebSphere Application Server InfoCenter for instructions on disabling JIT compiling in a WebSphere Application Server environment at http://www.ibm.com/software/webservers/appserv/infocenter.html.

Disabling JIT compiling can affect the performance of the JVM significantly especially during periods of high load.

4XESTACKTRACE at com.ibm.ws.util.BoundedBuffer.

  take(BoundedBuffer.java(Inlined Compiled Code))

4XESTACKTRACE at com.ibm.ws.util.ThreadPool.

  getTask(ThreadPool.java(Compiled Code))