On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen <kdnil...@openjdk.org> wrote:
> 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. Issues already reported to GenShen engineers: gc/shenandoah/TestElasticTLAB.java#generational # Internal Error (src\hotspot\share\gc\shenandoah\shenandoahFreeSet.cpp:695), pid=23288, tid=23784 # assert(size % CardTable::card_size_in_words() == 0) failed: size must be multiple of card table size, was 258 gc/stress/gcold/TestGCOldWithShenandoah.java#generational # Internal Error (src\hotspot\share\gc\shenandoah\heuristics\shenandoahOldHeuristics.cpp:82), pid=20828, tid=5836 # assert(_old_generation->available() > old_evacuation_budget) failed: Cannot budget more than is available gc/shenandoah/oom/TestAllocOutOfMemory.java#large Execution failed: `main' threw exception: java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr (Issue with 64k Pages) gc/shenandoah/TestRetainObjects.java#no-tlab gc/shenandoah/TestSieveObjects.java#no-tlab Timeouts. gc/shenandoah/TestAllocObjects.java#generational gc/shenandoah/TestDynamicSoftMaxHeapSize.java#generational # Internal Error src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp:664), pid=18434, tid=29955 # assert(is_global() || ShenandoahHeap::heap()->is_full_gc_in_progress() || (_used + _humongous_waste <= _affiliated_region_count * ShenandoahHeapRegion::region_size_bytes())) failed: used cannot exceed regions ------------- PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1571947174
