> OpenJDK Colleagues: > > Please review this proposed integration of Generational mode for Shenandoah > GC under https://bugs.openjdk.org/browse/JDK-8307314. > > Generational mode of Shenandoah is enabled by adding > `-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` to a > command line that already specifies ` -XX:+UseShenandoahGC`. The > implementation automatically adjusts the sizes of old generation and young > generation to efficiently utilize the entire heap capacity. Generational > mode of Shenandoah resembles G1 in the following regards: > > 1. Old-generation marking runs concurrently during the time that multiple > young generation collections run to completion. > 2. After old-generation marking completes, we perform a sequence of mixed > collections. Each mixed collection combines collection of young generation > with evacuation of a portion of the old-generation regions identified for > collection based on old-generation marking information. > 3. Unlike G1, young-generation collections and evacuations are entirely > concurrent, as with single-generation Shenandoah. > 4. As with single-generation Shenandoah, there is no explicit notion of eden > and survivor space within the young generation. In practice, regions that > were most recently allocated tend to have large amounts of garbage and these > regions tend to be collected with very little effort. Young-generation > objects that survive garbage collection tend to accumulate in regions that > hold survivor objects. These regions tend to have smaller amounts of > garbage, and are less likely to be collected. If they survive a sufficient > number of young-generation collections, the “survivor” regions are promoted > into the old generation. > > We expect to refine heuristics as we gain experience with more production > workloads. In the future, we plan to remove the “experimental” qualifier > from generational mode, at which time we expect that generational mode will > become the default mode for Shenandoah. > > **Testing**: We continuously run jtreg tiers 1-4 + hotspot_gc_shenandoah, > gcstress, jck compiler, jck runtime, Dacapo, SpecJBB, SpecVM, Extremem, > HyperAlloc, and multiple AWS production workload simulators. We test on Linux > x64 and aarch64, Alpine x64 and aarch64, macOS x64 and aarch64, and Windows > x64.
Kelvin Nilsen has updated the pull request incrementally with 174 additional commits since the last revision: - 8309614: [BACKOUT] JDK-8307153 JVMTI GetThreadState on carrier should return STATE_WAITING Reviewed-by: azvegint - 8308288: Fix xlc17 clang warnings and build errors in hotspot Reviewed-by: goetz, mbaesken - 8309225: Fix xlc17 clang 15 warnings in security and servicability Reviewed-by: goetz, mdoerr, clanger - 8309219: Fix xlc17 clang 15 warnings in java.base Reviewed-by: goetz, mdoerr - 8307153: JVMTI GetThreadState on carrier should return STATE_WAITING Reviewed-by: amenkov, cjplummer - 8309543: Micro-optimize x86 assembler UseCondCardMark Reviewed-by: kvn, mdoerr - 8280982: [Wayland] [XWayland] java.awt.Robot taking screenshots Reviewed-by: prr, kizune, psadhukhan - 8309550: jdk.jfr.internal.Utils::formatDataAmount method should gracefully handle amounts equal to Long.MIN_VALUE Reviewed-by: stuefe, mgronlun - 8308445: Linker should check that capture state segment is big enough Reviewed-by: mcimadamore - 8308031: Linkers should reject unpromoted variadic parameters Reviewed-by: mcimadamore - ... and 164 more: https://git.openjdk.org/jdk/compare/240d413d...8b2edd9c ------------- Changes: - all: https://git.openjdk.org/jdk/pull/14185/files - new: https://git.openjdk.org/jdk/pull/14185/files/240d413d..8b2edd9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14185&range=13-14 Stats: 55913 lines in 825 files changed: 45254 ins; 7582 del; 3077 mod Patch: https://git.openjdk.org/jdk/pull/14185.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14185/head:pull/14185 PR: https://git.openjdk.org/jdk/pull/14185
