Diagnostic data and tooling
OpenJ9 contains extensive trace and debugging capabilities to help identify, isolate, and solve run time problems. Various types of dumps are produced by default in response to certain events, such as a GPF fault or an
OutOfMemoryError exception. You can also trigger the production of dumps by using the
com.ibm.jvm.Dump API or by specifying
-Xdump options on the command line.
All dumps are produced by dump agents, which are initialized when the OpenJ9 VM starts. Different dumps target different areas of the runtime environment. If you want to generate a dump to diagnose a particular type of problem, you need to understand what data the dump will provide. The following dumps are typically used for problem diagnosis:
- Java dumps (
-Xdump:java) contain information that relates to the OpenJ9 VM and the Java™ application, such as the operating environment, locks, threads, hooks, shared classes, and class loaders.
- Heap dumps (
-Xdump:heap) show the content of the Java heap.
- System dumps (
-Xdump:system) contain a raw process image or address space of an application.
Other types of dump include binary JIT dumps, stack dumps, and snap dumps. For a complete list of dump agents and the diagnostic data they produce, see Dump agents.
Verbose log files
Some components of OpenJ9 can also produce verbose output or log files to assist with problem determination.
Class data sharing provides a number of
-Xshareclassessuboptions to provide detailed data about the content of a shared classes cache, cache I/O activity, and information about the Java Helper API (where used). For example, the
-Xshareclasses:printAllStatssuboption lists every class in chronological order with a reference to the location from which it was loaded. For more information, see -Xshareclasses.
Garbage collection operations can be analyzed by producing verbose output from the
-verbose:gcstandard option. This output can be redirected to a file by specifying the
-Xverbosegclogoption. Information can be obtained about GC initialization, stop-the-world processing, finalization, reference processing, and allocation failures. Even more granular information can be obtained with the -Xtgc option.
The JIT compiler provides verbose logging, which records all compiler operations. To find out how to enable logging, read the JIT troubleshooting content.
Class loader operations can be analyzed by producing verbose output from the
-verbose:dynloadstandard option, which shows detailed information as each class is loaded by the VM.
The OpenJ9 trace facility can be used to trace applications, Java methods, or internal JVM operations with minimal impact on performance. Trace is configured by using the -Xtrace command line option, which allows you to control what is traced and when.
Trace data is produced in binary format and must be processed by the OpenJ9 trace formatter to convert it to a readable form. For more information, see Trace formattter.
Debugging tools and interfaces
Because system dumps are binary files, OpenJ9 provides a dump viewer tool (
jdmpview) to analyze the contents. This tool can work with dumps from any platforms independently of a system debugger. For more information, see Dump viewer.
JVMTI tools interface
OpenJ9 supports the Java Virtual Machine Tool Interface (JVMTI) and provides extensions that allow JVMTI tools to obtain diagnostic information or trigger diagnostic operations in the VM. For more information, see JVMTI extensions.
OpenJ9 includes the Diagnostic Tool Framework for Java (DTFJ) API. Custom applications can be written that use this API to access a wide range of information in a system dump or a Java dump. For more information, see Using DTFJ.
OpenJ9 is compliant with the Java Platform Debugging Architecture (JPDA), which means you can use any JPDA tool for diagnosis, including Eclipse JDT Debug.