Guide to Eclipse OpenJ9 JVM

Last updated: June 13, 2025

Written by: Kostiantyn Ivanov

Reviewed by: David Martinez

Refactor Java code safely — and automatically — with OpenRewrite.

Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.

Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.

Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.

Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.

Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.

In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:

>> Flexible Pub/Sub Messaging With Spring Boot and Dapr

1. Overview

OpenJ9 is a high-performance, scalable, and flexible Java Virtual Machine. We can use it as a replacement for HotSpot in many Java applications. IBM originally developed it as part of its commercial JDK. Now this JVM is supported by the Eclipse Foundation.

We use OpenJ9 to reduce memory footprint and startup time, especially in cloud and container environments. It supports the Java SE specification and works well with OpenJDK. In this article, we’ll explore how to install OpenJ9 JVM and review its main features.

2. Installation

We can install OpenJ9 by downloading a prebuilt OpenJDK binary that includes it. Many distributions, like Eclipse Temurin, offer builds with OpenJ9. The official release list is on the Eclipse OpenJ9 website.

After downloading the archive, we extract the files and set the JAVA_HOME environment variable.

2.1. Windows

First, we extract the ZIP archive to a preferred location, such as path-to-jdk\jdk-openj9. Then we set the JAVA_HOME environment variable and modify the PATH environment variable:

Finally, we verify the installation:

$ java -version

2.2. Linux

First, let’s extract the archive:

Then we set JAVA_HOME and update the PATH:

We can add these lines to .bashrc, or .zshrc to make them permanent. Finally, we check the installation:

Now we’re ready to use OpenJ9 for running and developing Java applications.

3. Garbage Collection Policies

OpenJ9 offers multiple garbage collection policies. Each policy is optimized for different workloads. We can choose the policy that fits our performance goals.

In the HotSpot JVM, we configure garbage collection by selecting a GC implementation and tuning many parameters. In OpenJ9, we use GC policies instead. Each policy is designed for a specific use case, and we choose one at startup using the virtual machine option:

-Xgcpolicy:<name>

Let’s look at the available GC policies in OpenJ9.

3.1. Generational Concurrent GC Policy

This is the default policy and we’ll use it for most applications. Using this GC policy, we split the heap into two areas: nursery and tenure. This policy manages two generation groups: new and older.

It performs global GC using concurrent mark-sweep, optionally followed by compaction. Partial GC is a stop-the-world scavenge or concurrent scavenge.

We enable it with the following flag:

-Xgcpolicy:gencon

3.2. Balanced Policy

We use this policy for large heaps and many threads when we face unacceptable pause times with gencon. This policy divides the heap into equal-sized regions and obtains the support of multiple generations.

Global GC uses incremental concurrent marking. Partial GC uses a stop-the-world and optional mark, sweep, or compaction.

We can add this policy using the flag:

-Xgcpolicy:balanced

3.3. Optimize for Pause Time Policy

We choose this policy to minimize pause times. For example, it may be useful when we have a large heap size and it affects the length of the GC pause. This policy uses a single, flat heap area. Here we have only one generation.

GC is concurrent mark-sweep with optional compaction.

To start using this policy we have to add the following flag:

-Xgcpolicy:optavgpause

3.4. Optimize for Throughput Policy

We select this policy when we want maximum throughput in short-lived applications. We have a flat heap area here. This policy supports one generation.

GC is a stop-the-world mark-sweep with optional compaction.

We can enable this policy using the following flag:

-Xgcpolicy:optthruput

3.5. Metronome Policy

We use this policy for real-time and soft real-time applications. It splits the heap into size-classed regions. Here we have the support of one generation.

The metronome GC runs in short interruptible bursts to avoid long stop-the-world pauses.

To use the metronome policy, we can turn on the flag:

-Xgcpolicy:metronome

3.6. nogc Policy

We use this policy for testing or special use cases where memory isn’t reclaimed. We have a flat heap here. No GC is performed.

We can enable it using the following flag:

-Xgcpolicy:nogc

OpenJ9 supports Class Data Sharing and Ahead-of-Time compilation out of the box. We can use these features to improve startup time and reduce memory usage.

Class Data Sharing allows us to cache class metadata in a shared memory cache. We create a shared class cache once and reuse it across JVM runs. This speeds up class loading and reduces memory footprint, especially in container and microservice environments.

To enable CDS, we start the JVM with the following flag:

-Xshareclasses

We can also name the cache and control its size:

-Xshareclasses:name=myCache,cacheDir=/path/to/cache,cacheSize=100M

To view cache statistics, we use:

-Xshareclasses:cacheStats

4.2. Ahead-of-Time Compilation

Ahead-of-time compilation in OpenJ9 compiles Java bytecode into native code before runtime. This reduces JIT warm-up time and improves performance on startup.

Unlike HotSpot, which requires GraalVM for AOT, OpenJ9 has built-in support. The VM automatically chooses which methods should be AOT-compiled based, but we can disable it using the following flag:

-Xnoaot

5. Diagnostic Data and Tooling

OpenJ9 supports JMX, just like HotSpot. We can connect existing monitoring tools to it.

Additionally, OpenJ9 provides other tools that we can use to troubleshoot performance issues, crashes, or memory problems. We can use dump agents to generate heap dumps, system dumps, and general JVM information dumps.

To monitor CPU, memory, GC, and thread activity in real time, we could utilize the IBM Health Center.

6. Conclusion

In this tutorial, we saw how OpenJ9 can be a great choice when we want to reduce memory usage and speed up startup time. It works well for cloud workloads, microservices, and containerized apps. However, before using OpenJ9 in production, we should test it with our specific workload.

The same advice applies to GC policy selection. Each policy targets a different use case. We need to measure and compare to choose the best one.

With the right setup, OpenJ9 can deliver solid performance and save resources.