Summary

Make the G1 Garbage Collector (G1) the one true default collector that is always selected by default regardless of environment.

Goals

When specifying no garbage collection algorithm on the command line:

• Always select the G1 garbage collector if not specified otherwise, independent of the environment.
• In cases where VM ergonomics previously selected the Serial collector performance metrics (throughput, latency, native memory footprint, startup time) should not degrade significantly.

Non-Goals

It is not a goal of this JEP to:

• Prohibit future default garbage collector decisions. As typical application profiles and garbage collection algorithms change, the default garbage collection algorithm should be re-evaluated.
• Interfere with user selection: explicit garbage collection algorithm user selection will always override the ergonomic choice.
• Deprecate or remove any existing garbage collection algorithms including the Serial collector.
• Changes to the G1 functionality or behavior.

Motivation

The HotSpot Java Virtual Machine (JVM) provides automatic dynamic memory management (garbage collection) that continuously identifies and removes unused objects, freeing up memory to be reused by the application. This allows developers to focus on application development without worrying about manual memory management. Garbage collection improves productivity as it eliminates many classes of memory management related application errors.

Different applications have different requirements on the performance metrics throughput, latency, footprint and startup behavior. For this reason the JVM provides multiple garbage collection algorithms that focus on one or more of these aspects, including the Garbage-First (G1) garbage collector. According to JEP 248 ergonomics currently typically selects G1 if the user did not specify a different garbage collector on the command line.

G1 is a multi-threaded garbage collection algorithm that tries to balance throughput and latency. At the time of making G1 the default garbage collector, tests showed that on very small deployments (single CPU, small Java maximum heap sizes), the Serial collector provided significant advantages in throughput and footprint. At that time we implemented an exception for these situations and have ergonomics choose the Serial collector as the garbage collection algorithm.

Since then, the G1 collector improved in all aspects, and testing has shown that G1 is now very competitive with the Serial collector at all heap sizes. With JEP XXX, G1 maximum throughput improved significantly. Maximum latencies provided by G1 have always been better than the Serial collector's due to using incremental garbage collection instead of performing full heap collections. Finally, native memory usage has been reduced to Serial collector levels in recent releases to a degree where testing has shown that there is little difference in this aspect at the Java heap size the Serial collector has been chosen before too. In case total memory footprint is extremely important, G1 often even outperforms the Serial collector with appropriately reduced Java heap size that results in equal total memory footprint.

So we believe that current G1 garbage collector performance is sufficient to replace the Serial collector in all situation ergonomics would have selected it before.

Having only one garbage collection algorithm selected in all situations if the user did not indicate otherwise, improves consistency and clarity about JVM ergonomic choices. Further it reduces confusion and surprises when running the JVM without an explicit choice.

Description

If the user did not specify any garbage collection algorithm on the command line, G1 will always be selected regardless of the number of processor resources and Java heap size.

The JVM previously selected the Serial collector when run in an environment with only one CPU and less than approximately 1.8GB of Java heap. This will not be the case any more.

Testing

This enhancement only affects JVM performance metrics for small deployments (1 CPU, <= 1.8 GB of Java heap size). Therefore, we will thoroughly performance-test the G1 collector with a wide variety of workloads. The success metrics is that there is no significant difference in all of these benchmarks in this environment.

Risks and Assumptions

We assume that the G1 garbage collection algorithm's performance metrics are sufficiently close to the Serial collector's. There will be outliers, but we think that at worst the end user can still select the Serial collector manually.