JEP draft: Ergonomics Always Select the G1 Garbage Collector as Default

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. G1 is currently typically selected if the user does not specify a different garbage collector on the command line as implemented in JEP 248.

G1 is a multi-threaded garbage collection algorithm that tries to balance throughput and latency. At the time of making G1 default, tests showed that on very small deployments (single CPU, small Java maximum heap size), the Serial collector provided significant advantages in throughput and footprint, so an exception has been made for these situations. In these cases, ergonomics selects the Serial collector is selected as the garbage collection algorithm if not otherwise specified.

Since then, the G1 collector improved in all aspects, and testing showed that G1 is now very competitive with the Serial collector at all heap sizes. Particularly with JEP XXX, G1 throughput improved significantly. Native memory usage has been reduced to Serial collector levels in recent releases: testing showed that there is little difference at the Java heap size the Serial collector has been chosen before. In case it is relevant, 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.

G1's incremental garbage collections will improve maximum latency too as the Serial collector's whole heap collection at the upper end of the Java heap size range ergonomics selects it can be very long.

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, and 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 primarily affects 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.