On Wed, 7 Jun 2023 00:39:52 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. > > Kelvin Nilsen has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright notices > Hi, I have built this pr based on > [aa85a90](https://github.com/openjdk/jdk/commit/aa85a9073e2a71d6bf920409e739d555f9dcf302), > Tier1 tests failed on `gc/TestAllocHumongousFragment.java#generational` on > Linux/RISC-V with the following output: > > ``` > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (shenandoahVerifier.cpp:1244), pid=2951116, tid=2951124 > # Error: Verify init-mark remembered set violation; clean card should be > dirty > # > # JRE version: OpenJDK Runtime Environment (21.0) (build > 21-internal-adhoc.ubuntu.jdk) > # Java VM: OpenJDK 64-Bit Server VM (21-internal-adhoc.ubuntu.jdk, mixed > mode, sharing, tiered, compressed oops, compressed class ptrs, shenandoah gc, > linux-riscv64) > ``` > > Looks like Generational Shenandoah does not fully support RISC-V port, should > we disable this test on RISC-V port for now? Fixed (platform disabled) by @kdnilsen in https://github.com/openjdk/jdk/pull/14185/commits/cc149904d76c78355fc994da171f0f21411e903f ------------- PR Comment: https://git.openjdk.org/jdk/pull/14185#issuecomment-1579829038
