OpenJ9

The Just-In-Time (JIT) improves the performance of Java applications by compiling platform-neutral Java bytecode into native machine code at run time. Not every method that gets called by an application is compiled. Instead, OpenJ9 records the number of times a method is called and triggers JIT compilation at a predefined threshold. The JIT compiler compiles methods at different optimization levels: cold, warm, hot, very hot (with profiling), or scorching. The hotter the optimization level, the better the expected performance, but the higher the cost in terms of CPU and memory. The higher optimization levels use special techniques such as escape analysis and partial redundancy elimination, or loop through certain optimization sequences more times. Although these techniques use more CPU and memory, the improved performance that is delivered by the optimizations can make the trade-off worthwhile.

Ahead of Time (AOT) compilation is a mechanism for improving start up performance. Methods are dynamically compiled into AOT code at runtime, which enables the JVM to start an application faster. AOT is enabled automatically when class data sharing is used (-Xshareclasses) and doesn't require any special tuning. OpenJ9 automatically chooses which methods to compile based on heuristics that identify the start-up phase of large applications. For small or short running applications, the -Xtune:virtualized option should be added to get the most out of AOT-compiled code.

Sharing class data between JVMs has two main benefits:

1. Start up performance is improved by placing classes that an application needs when initializing into a shared classes cache.
2. Memory footprint is reduced by sharing common classes between applications that run in separate Java VMs.

Unlike other class data sharing (CDS) implementations, enabling the feature in OpenJ9 requires only one step: setting -Xshareclasses on the command line when you start your application. When specified, OpenJ9 creates a memory mapped file to store and share the classes in memory. By default, OpenJ9 always shares both the bootstrap and application classes that are loaded by the default system class loader. Another benefit of the OpenJ9 CDS implementation is that the cache is updated dynamically. So when an application loads new classes, the JVM automatically stores them in the cache without any user intervention.[9]

OpenJ9 also provides a public Helper API for integrating class sharing support into custom class loaders, plus several utilities for managing active caches.

To prevent applications running out of memory, objects in the Java heap that are no longer required must be reclaimed. This process is known as garbage collection (GC). OpenJ9 provides a number of garbage collection policies that are designed around different types of applications and workloads. Choosing the right policy depends on usage and performance goals. By default, OpenJ9 uses the Generational Concurrent (-Xgcpolicy:gencon) policy, which is best suited to transactional applications that have many short lived objects. Alternative policies are available, including those that cater for applications with large Java heaps (-Xgcpolicy:balanced), applications that are sensitive to response-time (-Xgcpolicy:metronome), or applications that require high application throughput (-Xgcpolicy:optthruput).

An "idle tuning" option (-XX:+IdleTuningGcOnIdle) triggers garbage collection in OpenJ9 when the application is idle. Doing this reduces memory footprint, meaningful for some virtual hosting billing plans.[7]

In January 2020, OpenJ9 delivered an experimental feature to JIT compile code outside JVM and remotely on a server.

OpenJ9 contains extensive trace and debugging utilities to help identify, isolate and solve runtime problems. Different types of diagnostic data are automatically produced by default when certain events occur, but can also be triggered from the command line. Types of data include:

Java dumps

These are produced when the JVM ends unexpectedly because of an operating system signal, OutOfMemoryError exception, or a user initiated keystroke combination. Java dumps summarize the state of the JVM when the event occurs, with most of the information relating to components of the JVM.

Heap dumps

Heap dumps show all the live objects on the Java heap when the JVM ends because of an OutOfMemoryError exception or when requested by a user. The information includes object address, type or class name, size, and references to other objects. Analyzing heap dumps might tell you which objects are using large amounts of memory on the Java heap and why these are not being garbage collected.

System dumps

Often known as core dumps, these are platform-specific and contain a raw binary dump of the process memory. This dump has a complete copy of the Java heap, including the contents of all Java objects in the application. OpenJ9 tools are available to process the system dump into a readable format for analysis.

Garbage collection data

To analyze garbage collection problems you can enable verbose logging, which provides data on all garbage collection operations including initialization, stop-the-world processing, finalization, reference processing, and allocation failures. For even more detailed analysis, you can turn on garbage collection tracing.

Trace data

The OpenJ9 trace facility can be used to trace applications, Java methods, or internal JVM operations with minimal impact on performance.

JIT data

If a general protection fault or abort event takes place, the JIT produces a small binary dump that can be analyzed by OpenJ9 developers to help determine the root cause.

Shared classes data

The shared classes data component provides some verbose options that can be used at runtime to show cache activity. The printStats and printAllStats utilities allow you to analyze the contents of a shared class cache.

The diagnostic component also includes the DTFJ application programming interface, which can be used to build diagnostic tools. DTFJ works with data from a system dump or a Java dump.