by Nicolai Parlog on July 20, 2026

The OpenJDK Quality Group is promoting the testing of FOSS projects with OpenJDK builds as a way to improve the overall quality of the release. This heads-up is part of a Quality Outreach update sent to the projects involved. To learn more about the program, and how-to join, please check here.

In situations where no garbage collector is specified on the command line, the HotSpot JVM used to select either G1 GC or Serial GC, depending on the environment. It preferred G1, but due to Serial's past throughput and footprint advantages in constrained environments, the JVM would select the latter if only a single CPU or less than 1792 MB of physical memory was detected.

Recent work has made G1 competitive with Serial in those environments. Generally speaking, G1 will have similar native memory overhead, slightly lower throughput, and lower maximum latencies than Serial. To make it easier to reason about the JVM's behavior, starting with JDK 27, it picks G1 as default garbage collector in all environments.

This change:

  • does not remove Serial GC from the JDK, which remains available in situations where its performance characteristics are preferable

  • does not interfere with applications that select a specific garbage collector on the command line

  • does not interfere with applications that run in environments with multiple CPUs and more than 1792 MB of memory

That means an application is only impacted by this change if it runs in a constrained environment and doesn’t select a garbage collector. In such cases we recommend to benchmark the application against different GCs to pick the one that best suits its needs. If that is not possible, it can either accept G1 as the new default or configure Serial to guarantee no change in GC-related performance characteristics.

For more information, please check JEP 523.

~