RFR: Restrict generational mode to adaptive heuristic

Aleksey Shipilev shade at openjdk.org
Mon Mar 27 10:12:45 UTC 2023


On Fri, 24 Mar 2023 18:59:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a small change to Shenandoah, but it prevents us from running the tests with the generational mode enabled via a jtreg vm option. This requires us to properly integrate the generational mode with the jtreg tests. There are many test files changed, but the `generational` mode is now handled in the same fashion as other modes (`iu`, `passive`). There are two additional advantages to these changes:
> * We no longer need to run the test suite twice (once in the default mode and again with `-XX:ShenandoahGCMode=generational`).
> * Expanded test coverage, as some tests would spawn their own VMs with permutations of mode and heuristic options that ignored the generational mode.

Questions and suggestions below:

test/hotspot/jtreg/gc/shenandoah/TestAllocHumongousFragment.java line 61:

> 59:  *
> 60:  * @run main/othervm -Xmx1g -Xms1g -Xlog:gc -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:ShenandoahTargetNumRegions=2048
> 61:  *      -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:ShenandoahGCMode=satb

Why add `satb` in this test, but not the others? Other tests seem to just run `aggressive` with default GC mode.

test/hotspot/jtreg/gc/shenandoah/TestAllocObjectArrays.java line 121:

> 119:  *      -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational
> 120:  *      -XX:+ShenandoahOOMDuringEvacALot -XX:+ShenandoahVerify
> 121:  *      TestAllocObjectArrays

Please put `-XX:+ShenandoahVerify` on the separate line, like the test config above?

test/hotspot/jtreg/gc/shenandoah/TestAllocObjectArrays.java line 167:

> 165:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -Xmx1g -Xms1g
> 166:  *      -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational
> 167:  *      -XX:-UseTLAB -XX:+ShenandoahVerify

This `-XX:+ShenandoahVerify` seems excessive. This config is supposed to run without verification. Copy-paste error, it seems.

test/hotspot/jtreg/gc/shenandoah/TestParallelRefprocSanity.java line 1:

> 1: /*

Why is this removed?

test/hotspot/jtreg/gc/shenandoah/TestRegionSamplingLogging.java line 31:

> 29:  * @run main/othervm -Xmx1g -Xms1g -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions
> 30:  *      -XX:+ShenandoahRegionSampling -XX:+ShenandoahRegionSampling
> 31:  *      -Xlog:gc+region=trace:region-snapshots-%p.log::filesize=100,filecount=3

So, `trace` is enough here? This looks like something we need to fix upstream, rather than do in a bulk change like this.

test/hotspot/jtreg/gc/shenandoah/TestRetainObjects.java line 107:

> 105:  * @run main/othervm -Xmx1g -Xms1g -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions
> 106:  *      -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational
> 107:  *      -XX:+ShenandoahAllocFailureALot -XX:+ShenandoahVerify

I think the intent here is to run without `-XX:+ShenandoahVerify`.

test/hotspot/jtreg/gc/shenandoah/TestSieveObjects.java line 107:

> 105:  * @run main/othervm -Xmx1g -Xms1g -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions
> 106:  *      -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational
> 107:  *      -XX:+ShenandoahAllocFailureALot -XX:+ShenandoahVerify

Excessive `-XX:+ShenandoahVerify`?

test/hotspot/jtreg/gc/shenandoah/compiler/BarrierInInfiniteLoop.java line 35:

> 33:  */
> 34: 
> 35:  /**

This looks like a compiler regression test, so we don't need to run it in all these different GC modes.

test/hotspot/jtreg/gc/shenandoah/compiler/CallMultipleCatchProjs.java line 34:

> 32:  */
> 33: 
> 34:  /**

Again, compiler regression test, probably no reason to run with different GC modes.

test/hotspot/jtreg/gc/shenandoah/compiler/FoldIfAfterExpansion.java line 36:

> 34:  */
> 35: 
> 36: /**

Again, compiler regression test, probably no reason to run with different GC modes.

test/hotspot/jtreg/gc/shenandoah/compiler/LRBRightAfterMemBar.java line 35:

> 33:  */
> 34: 
> 35:  /**

Right, `compiler` test again. :) I think most (all?) tests in this folder do not need GC mode variance.

test/hotspot/jtreg/gc/shenandoah/compiler/TestClone.java line 208:

> 206:  */
> 207: 
> 208: /*

This one seems to be the rare exception where GC mode variance is meaningful -- this is not a targeted regression test.

test/hotspot/jtreg/gc/shenandoah/generational/TestCLIModeGenerational.java line 34:

> 32:  * @library /testlibrary /test/lib /
> 33:  * @build jdk.test.whitebox.WhiteBox
> 34:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox

Generally, these changes should be done separately, not to clobber the actual "generational"-related test change. It is fine to do them here, if these only touch the files than exist only in GenShen.

test/hotspot/jtreg/gc/shenandoah/oom/TestAllocOutOfMemory.java line 35:

> 33: /**
> 34:  * @test id=heap
> 35:  * @summary Test allocation of small object to result OOM, but not to crash JVM

The `@summary` in these configs are all the same, copy-paste error.
Also, we might want to fix English here a bit:
`Test allocation of (small|large|larger-than-heap) object should result in OOM, not in JVM crash`.

test/hotspot/jtreg/gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java line 1:

> 1: /*

Is there a generational variant for this?

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/233#pullrequestreview-1358736166
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149058740
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149060202
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149061221
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149065439
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149070147
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149070925
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149071593
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149073540
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149074305
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149074544
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149075454
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149076687
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149077952
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149086518
PR Review Comment: https://git.openjdk.org/shenandoah/pull/233#discussion_r1149089962


More information about the shenandoah-dev mailing list