JEP 523: Make G1 the Default Garbage Collector in All Environments

Summary

Make the Garbage-First (G1) garbage collector the default collector in all environments, rather than just server environments.

Goals

When no garbage collector is specified on the command line:

• The HotSpot JVM will always select G1.

• In scenarios in which the JVM previously selected the Serial collector, the performance metrics of throughput, latency, memory footprint, and startup time should not degrade significantly.

Non-Goals

It is not a goal to:

• Prohibit future changes of the default garbage collector. As typical application profiles change and collector performance evolves, the default collector should be re-evaluated.

• Interfere with user selection: A collector chosen explicitly will always override the JVM’s selection.

• Deprecate or remove any existing collector.

• Change the functionality or behavior of G1.

Motivation

The HotSpot Java Virtual Machine (JVM) provides automatic dynamic memory management, i.e., garbage collection, which continuously identifies and removes unused objects, freeing memory to be reused by the application. This allows developers to write code without worrying about memory management. Garbage collection improves productivity since it eliminates many classes of application errors related to memory management.

Different applications have different requirements on the performance metrics of throughput, latency, footprint, and startup time. The JVM therefore includes multiple garbage collectors, each of which focuses on different combinations of these metrics. For example, ZGC prioritizes latency and Parallel prioritizes throughput, while G1 is designed to balance latency and throughput. If you know which collector is best for your application then you can specify it when you start the JVM; otherwise, the JVM will select one for you.

We made G1 the default collector for server environments in JDK 9 (JEP 248). At that time, testing showed that Serial had significant advantages in throughput and footprint in constrained environments with a single CPU and less than 1.8 GB of heap. We therefore adjusted the JVM's GC selection algorithm to choose Serial in such environments.

Since then, we have improved the G1 collector across all metrics, and testing shows that G1 is now competitive with Serial at all heap sizes. With our recent work to reduce synchronization (JEP 522), G1's maximum throughput is close to that of Serial. G1's maximum latencies have always been better than those of Serial, since G1 reclaims memory in the old generation via incremental garbage collections rather than full collections. Finally, in recent releases we have reduced G1's native memory usage to levels comparable to that of Serial.

G1's performance is now sufficient to replace Serial in all situations in which the JVM would previously have selected Serial. It is time to stop selecting Serial by default in constrained environments. This will also make it easier to understand and reason about the JVM’s behavior.

Description

If you do not specify a garbage collector on the command line then the JVM will always select G1, regardless of the number of processors and the Java heap size.

Testing

This change only affects JVM performance metrics in constrained environments. Therefore, we will thoroughly performance-test G1 and compare it with Serial on a wide variety of workloads in such environments. There should be no significant differences in performance.

Risks and Assumptions

It is possible that some applications in constrained environments will still perform best with Serial. In such cases, you can still select Serial explicitly.