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 (email@example.com
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.
- 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.