跳到主要内容

JEP 474: ZGC: Generational Mode by Default

Summary​

Switch the default mode of the Z Garbage Collector (ZGC) to the generational mode. Deprecate the non-generational mode, with the intent to remove it in a future release.

Goals​

  • Signal the intent that future development will focus on Generational ZGC.

  • Reduce the maintenance cost of supporting two different modes.

Non-Goals​

  • It is not a goal to remove non-generational ZGC from the targeted release.

Motivation​

Maintaining non-generational ZGC slows the development of new features. As stated in JEP 439: Generational ZGC:

Generational ZGC should be a better solution for most use cases than non-generational ZGC. We should eventually be able to replace the latter with the former in order to reduce long-term maintenance costs.

Description​

Make Generational ZGC the default mode of ZGC by changing the default value of the ZGenerational option from false to true. Deprecate the non-generational mode by deprecating the ZGenerational option.

After these changes the following behavior will be observed based on the provided command-line arguments:

  • -XX:+UseZGC

    • Generational ZGC is used.

  • -XX:+UseZGC -XX:+ZGenerational

    • Generational ZGC is used.
    • A warning that the ZGenerational option is deprecated is issued.

  • -XX:+UseZGC -XX:-ZGenerational

    • Non-generational ZGC is used.
    • A warning that the ZGenerational option is deprecated is issued.
    • A warning that the non-generational mode is deprecated for removal is issued.

Workloads that switch to Generational ZGC may experience differences in log output and in the data available from the serviceability and management APIs.

Testing​

We will ensure that existing tests are unaffected by the deprecated option warning and that they pass in the same configurations as before this change.

Risks and Assumptions​

This JEP shares its Risk and Assumptions with JEP 439: Generational ZGC.

Generational ZGC will perform differently than non-generational ZGC. The main risk this presents is that some workloads are non-generational by nature, and thus could see a slight performance degradation. We believe that this is a sufficiently small set of workloads that it does not justify the cost of maintaining two separate versions of ZGC over the long term.

Specific risks include:

  • Users may be required to adjust configurations that are tuned for non-generational ZGC.

  • The deprecation warning messages might cause issues.

  • Workloads that are tightly coupled to JVM internals, GC logs, and the data available via management interfaces may require extra attention.