How To
Summary
IBM Thread and Monitor Dump Analyzer for Java (TMDA) is tool that allows identification of hangs, deadlocks, resource contention, and bottlenecks in Java thread dumps.
Steps
- Download jca*.jar: https://public.dhe.ibm.com/software/websphere/appserv/support/tools/jca/jca469.jar
- Open a terminal or command prompt and change directory to where you downloaded the JAR file.
- Ensure that Java is on your PATH to run the tool.
- Launch the tool: java -jar jca*.jar
The simplest way to request a thread dump on POSIX-based systems such as Linux is to send the kill -3 signal which non-destructively pauses the JVM, creates the thread dump, and the JVM continues (the pause is usually a few hundred milliseconds at most). For example (replace ${PID} with the process ID of the Java process):
kill -3 ${PID}
For other methods of requesting thread dumps and other operating systems, see the Related Information links at the bottom.
Additional Information
During the runtime of a Java™ process, it may not respond predictably and may seem to hang up for a long time or until JVM shutdown occurs. It is not easy to determine the root cause of these sorts of problems. By triggering one or more thread dumps when a Java process does not respond, it is possible to collect diagnostic information related to the JVM and a Java application captured at particular points during execution (note that another common cause of Java slowdowns is garbage collection, in which case you should review verbose garbage collection). For example, the information can be about the operating system, the application environment, threads, native stacks, locks, and memory. The exact contents are dependent on the platform and JVM on which the application is running.
Here is a screenshot of TMDA showing a single thread dump (the left half shows all threads in the thread dump), sorting by stack depth descending (as stack depth often correlates with non-idleness), and showing a thread stack that is suspicious (on the right half):
On some platforms, and in some cases, javacores are known as javadumps. The code that creates javacores is part of the JVM. One can control it by using environment variables and run-time switches. By default, a javacore occurs when the JVM terminates unexpectedly. A javacore can also be triggered by sending specific signals to the JVM. Although thread dumps are present in HotSpot JVMs (sent to stderr instead of a javacore.txt file), the content of javacores produced by the J9 JVM (IBM Java, OpenJ9) is much more rich.
This tool analyzes each thread and provides diagnostic information such as current thread information, the signal that caused the javacore, Java heap information (maximum Java heap size, initial Java heap size, garbage collector counter, allocation failure counter, free Java heap size, and allocated Java heap size), number of runnable threads, total number of threads, number of monitors locked, and deadlock information.
IBM Thread and Monitor Dump Analyzer for Java compares each javacore and provides process ID information for threads, time stamp of the first javacore, time stamp of the last javacore, number of garbage collections per minute, number of allocation failures per minute, time between the first javacore and the last javacore, number of hang suspects, and list of hang suspects.
This tool also compares all monitor information in javacores and detects deadlock and resource contention or monitor bottlenecks, if there are any.
The TMDA tool is provided as is without any warranty or support; however, we try to fix and enhance the tool as time permits. The tool was originally created by Jinwoo Hwang. Since Mr. Hwang's departure from IBM, the tool is maintained as time permits by Kevin Grigorenko (kevin.grigorenko@us.ibm.com).
Version history:
- 4.6.9
- Fix handling of thread dumps with "<name unavailable>NULL" and "1INTERNAL Unable to walk threads. Some or all threads may have been omitted." in the stack (also add a warning when clicking on such a parsed thread dump).
- 4.6.8
- Fix handling of thread dumps with newlines in the thread name.
- 4.6.7
- Fixed spurious deadlock warning when waiting on monitor that is unowned.
- 4.6.6
- Support HotSpot thread dumps with three spaces ( ) in front of stack frames instead of a tab (\t).
- 4.6.5
-
Support HotSpot thread dumps with thread name signature of " - Thread t@$ID" in addition to " prio=".
-
- 4.6.4
-
Fix Java heap virtual memory allocation calculations.
-
On macOS, by default, use the system look and feel so that the file dialogs and copy/paste are more natural. This behavior may be reverted at runtime by clicking View > Options and clicking OK.
-
- 4.6.3
- Fix issue where progress bar completes too early and selecting a javacore before the parsing fully completes can raise exceptions.
- Handle corrupted parked monitor lines in javacores.
Related Information
Document Location
Worldwide
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"LOB15","label":"Integration"}},{"Business Unit":{"code":"BU050","label":"BU NOT IDENTIFIED"},"Product":{"code":"SG9NGS","label":"IBM Java"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
03 March 2021
UID
ibm11108077