DEV Community: Sebastien Le Roy

The JVM / JDK ecosystem

Sebastien Le Roy — Mon, 10 Nov 2025 21:06:53 +0000

In the previous post, we discussed the Shenandoah Garbage Collector and I mentioned some distributions to explicit if this garbage collector is supported or not.

There is an element of confusion when we talk about JDK, JVM, Hotspot… as these terms are often referenced but not always well described, and unfortunately sometimes not used correctly. The goal of this post is to try to clarify the terms and try to describe the current ecosystem.

We need to introduce three different concepts:

– JVM

– Implementation SDK

– Distribution SDK

The JVM

The Java SE has a set of specifications (Language + JVM) that is lead by Oracle. They decide how the language evolve.

What we call a JVM in the everyday language is usually an implementation of the JVM specification. The job of the JVM is to execute the Java bytecode (compiled .class files). In the JVM we will find the class loading, execution of the bytecode, the Just In Time compiler, the memory management and different garbage collectors….

There are three main JVM implementations:

Hotspot : it is by far the dominant JVM, developed by Oracle
J9 : an alternative JVM that was originally developed by Oracle. Its goal was to optimize the memory footprint, the startup performance to have a JVM better fitted for enterprise-scaled applications. It was later donated to the Eclipse Foundation and now exists under the name OpenJ9
GraalVM : an alternative JVM developed by Oracle Labs with 2 main goals: replace the old Hotspot C2 compiler by a new compiler written in Java (Graal compler) so that it can be further developed and optimized and open the JVM to other languages (Python, Rust…). GraalVM is based on hotspot with some twists (different compiler + polyglot engine) rather than a full different JVM.

These 3 JVMs have a different profile and will fit different needs differently. The J9 JVM is known for consuming less memory but with the trade-off or lower throughputs, so it may be a good fit for containerized environments with less memory available.

The implementation JDK

To have a complete developer environment, we need to add on top of the JVM:

The core Java libraries (java.lang,java.util, java.io…)
The tooling to compile the code into bytecode (javac, jar…)
The supporting infrastructure to ease the developer experience: troubleshooting looks like JFR or jcmd, the JMX APIs, the certificate management tools like keytools or cacerts…

The implementation JDK provides an implementation for all the above and embeds the JVM. Each JVM has its own implementation JDK:

Hotspot -> OpenJDK
OpenJ9 JVM -> OpenJ9 JDK
GraalVM JVM -> GraalVM JDK

As for the JVM, the JDKs provide different tooling options. For example, GraalVM is famous for its AOT and native image compilation capabilities that reduce the memory footprints of the application and speed up startup time.

The distribution JDK

Now that there is a project providing an implementation of the JDK, it still needs to be packaged, tuned, tested, supported and patched. That is what the distribution provides.

There are a lot of distributions: some require a paid license and provide enterprise reliability, guaranteed long term support, certified builds, some are open source. At the distribution level, some vendors decide to disable some features that they do not want to support (ZGC, Shenandoah GC, experimental JVM options), tune the heap flags differently or provide extra crypto algorithms, telemetry agents or diagnostic tools.

I hope this article helped to clarify the difference between an implementation of the SDK and a distribution. It highlighted that there are alternatives to the traditional HotSpot JVM / OpenJDK and we’ll try OpenJ9 and GraalVM in practice. That will be the subject of future articles.

New in Java25: Generational Shenandoah GC is no longer experimental

Sebastien Le Roy — Sun, 14 Sep 2025 13:25:54 +0000

This article kicks off a series of posts related to the release of the new Java 25. We will focus on the changes that can impact application performance. In this post, we will focus on the Shenandoah garbage collector (GC) which now officially supports a generational algorithm.

What is the Shenandoah GC ?

The Shenandoah GC is one of the garbage collectors provided on the HotSpot JVM that can be enabled to manage the memory of the JVM. The following table lists the existing garbage collectors and their main usage for Hotspot:

Garbage Collector	Usage
Serial GC	Single-threaded collector, best suited for single-core machines or small applications
Parallel GC	Multi-threaded collector focused on maximizing throughput
Concurrent Mark-Sweep 🕱	Removed in JDK14
G1 GC	Designed to balance latency and throughput. Default GC
ZGC	Low-latency scalable collector with sub-millisecond pause times
Shenandoah	Low-pause-time collector like ZGC, also concurrent compaction.
No-op GC	Test only. Allocates memory but never reclaims it. Useful for testing and performance evaluation without GC overhead

The Shenandoah GC was introduced in 2019 with Java 12, and aims at providing a guaranteed low pause time for latency-sensitive applications. What you can expect with this GC is a pause time in the 1-10 milliseconds range, independently of the heap size.

To achieve this low level of pauses, the GC is almost fully concurrent. The memory is divided into regions, and the GC works to mark, evacuate and compact objects in some of the regions while the application is running. There is a small “stop the world” pause at the end of a collection cycle, but it is brief as most of the tasks were done while the application is running.

Let’s see how it compares with the other GC:

G1GC is the default garbage collector since JDK 9 because it is the most balanced garbage collector between throughput, memory usage and latency. G1GC is also a region-based garbage collector, but it only performs the marking phase while the application is running and needs to pause the application to perform the compaction phase. That explains why Shenandoah can provide lower latencies than G1GC (~200ms). The tradeoff is that Shenandoah requires more memory (10-20% overhead on the heap) compared to G1GC (<10%)

ZGC is a very interesting GC to compare with Shenandoah as they are both designed to be low-pause garbage collectors. So why do we have both ? Because they have been concurrently developed by different actors. ZGC has been developed by Oracle and released since JDK 11. Shenandoah has been developed by Red Hat and released since JDK 12. The Oracle JDK does not include Shenandoah in an effort to promote their own ZGC.

Even if they are both low-pause GC, Shenandoah has been designed for medium-sized heaps (8 to 64GB) while ZGC is designed for extra large heaps (hundreds of GBs and beyond).

What is the generational Shenandoah?

Generational GCs were developed based on the observation that most “objects die young” in the heap, and if these objects are not dead after a few collection cycles, there is no point checking them at every single collection because they will most likely live very long.

To reduce the collection cycle, Generational GCs split the heap into a space for recent objects (young) and a space for objects that survived a few cycles (old). The collection strategies differ for these different generations, which removes unnecessary scans and improves performance.

All mature GCs are generational, but the generational feature is often added after the initial release of the GC. ZGC was released in 2018 and added the generational feature in JDK 23. Remember that ZGC and Shenandoah are competitors and follow the same trajectory, so it was not a surprise to see the Generational Shenandoah released in JDK 24 as an experimental feature.

The generational Shenandoah should mostly improve the throughput and the memory footprint compared to non-generational Shenandoah. I have heard the number of ~30% higher throughput, but did not find any precise benchmark to corroborate this number.

What has changed for Shenandoah GC in Java 25 ?

In Java 24, the Shenandoah GC generational algorithm was released as an experimental feature, so that its correctness can be proven. You can use it in Java 24 using the following flags:

-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational
-XX:+UnlockExperimentalVMOptions

Between Java 24 and 25, the work continued on this GC to:

Stabilize the implementation and fix bugs and security issues
Improve performance by reducing scanning, GC overhead and reduce the variability of pauses
Optimize region handling to avoid promoting short-lived objects
Improve tooling and logging

Thanks to all these improvements, the Generational Shenandoah has now reached a level of maturity that makes it suitable for production-grade applications, and has been made an official feature. That means that if you were using it in Java 24, you do not need the experimental flag anymore, and if you were using the Shenandoah GC without the generational feature, it may be worth considering it.

⚡️ Spring Boot Performance: Avoid Default Config Pitfalls

Sebastien Le Roy — Sat, 19 Jul 2025 20:52:03 +0000

Spring Boot makes it easy to get started, but its default settings can quietly sabotage your performance

In this article, I explore real-world pitfalls in Spring Boot’s default configuration

Read the article