OpenJ9


Eclipse OpenJ9 is a high performance, scalable, Java virtual machine implementation that is fully compliant with the Java Virtual Machine Specification.
OpenJ9 can be built as a component of OpenJDK v8 and later, with prebuilt binaries available at the AdoptOpenJDK project for a number of platforms including Linux and Windows. OpenJ9 is also a core component of the IBM developer kit, which is embedded in many IBM middleware products, including WebSphere Application Server and Websphere Liberty. OpenJ9 is also a component of Open Liberty.
Extensive configuration options ensure that the JVM can be tuned to satisfy the requirements of a wide range of Java applications, from complex enterprise applications that run on mainframe hardware to short-lived applications that run on container-based cloud services.

History

OpenJ9 can trace its roots back to the ENVY/Smalltalk product developed by Object Technology International. IBM purchased OTI in 1996 for their Smalltalk expertise and products. However, when the Java language emerged as a leading language for the Enterprise market, the existing Smalltalk VM was adapted to process Java bytecodes instead. The name J9 evolved from the naming convention for the Smalltalk source code, K8. K→J because the developers believed that Smalltalk was better than Java, but 8→9 because the new VM would be better than before.
The J9 JVM became the runtime engine for many of IBMs Enterprise middleware products, where it has built its reputation for high performance, scalability, and reliability.
In 2017, J9 became an Eclipse Foundation project under the name Eclipse OpenJ9. IBM continue to be actively involved in the project and continue to put this Java VM at the core of many software offerings. At the Eclipse Foundation, OpenJ9 is classified as an incubator project, with the first release, v0.8.0, delivered in 2018.

Features

The Eclipse OpenJ9 JVM is fully compliant with the Java JVM specification. The same version of the JVM can be used in OpenJDK 8 and later releases, which means that many features and improvements can be exploited by applications that run on different versions of Java. Compared to Oracle's HotSpot VM, OpenJ9 touts higher start-up performance and lower memory consumption at a similar overall throughput.
Eclipse OpenJ9 embeds Eclipse OMR, which provides core runtime components that can be used to build runtime environments for different programming languages. At the OpenJ9 project, an extra layer of code adds the language semantics to provide a runtime environment for Java applications.
The components that make up Eclipse OpenJ9 are described in the following sections:

JIT Compiler

The Just-In-Time 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 , 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.

AOT Compiler

Ahead of Time 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 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.

Class data sharing

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 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.
OpenJ9 also provides a public Helper API for integrating class sharing support into custom class loaders, plus several utilities for managing active caches.

Garbage Collector

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. 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 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, applications that are sensitive to response-time, or applications that require high application throughput.
An "idle tuning" option triggers garbage collection in OpenJ9 when the application is idle. Doing this reduces memory footprint, meaningful for some virtual hosting billing plans.

JIT Server

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

Diagnostic Component

OpenJ9 contains extensive trace and debugging utilities to help identify, isolate and solve run time 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
;Heap dumps
;System dumps
;Garbage collection data
;Trace data
;JIT data
;Shared classes data
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.

Adoption