RFR: 8310187: Improve Generational ZGC jtreg testing
Axel Boldt-Christmas
aboldtch at openjdk.org
Fri Jun 16 09:22:33 UTC 2023
The current implementation for testing generational ZGC with jtreg is implemented with a filter on the mode flag `ZGenerational`. Because of this only environments which set this flag explicitly will run most of the tests.
So they get missed in Github Actions and for developers running jtreg locally without supplying the `ZGenerational` flag.
The proposed change here is to introduce two new jtreg requirement properties, `vm.gc.ZGenerational` and `vm.gc.ZSingelgen`. These flags will effectively behave the same as the existing `vm.gc.<GC>` flags but also take the specific ZGC mode in account.
If no gc flags are supplied to jtreg and the `vm.gc.Z` is true (the build includes ZGC) both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be true.
If `-XX:+UseZGC` is supplied then both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will also be true.
If `-XX:{+,-}ZGenerational` is supplied then either `vm.gc.ZGenerational` or `vm.gc.ZSingelgen` be true depending on the flags value.
And if `vm.gc.Z` is false both `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` will be false.
This change also splits the relevant tests into two distinct runs for the two modes. And the respective test ids are set to `ZGenerational` or `ZSinglegen` to make it easier to distinguish the runs.
This also solves the issue that some compiler tests will never run with generational ZGC unless the `TEST_VM_FLAGLESS` is set. This is because the current filter `vm.opt.final.ZGenerational` requires the flag to be explicit, but these compiler tests uses `vm.flagless`.
The introduction of `vm.gc.ZGenerational` and `vm.gc.ZSingelgen` harmonizes the way you specify generational / single gen ZGC test with the way it is done for other gcs with `vm.gc.<GC>`
To support this feature the Whitebox API is extended with `isDefaultVMFlag` to enable checking if `ZGenerational` is default or not.
`vm.opt.final.ZGenerational` is still kept because we still have some reasons to filter based on the supplied flags.
- `test/hotspot/jtreg/gc/cslocker/TestCSLocker.java` is disabled when running with ZGenerational
- `test/jdk/java/lang/ProcessBuilder/CloseRace.java` is ran with a different max heap size for ZGenerational, but it is not the intent to dispatch the test to both G1 and generational ZGC if Generational ZGC is not specified.
`test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed to not filter but instead dispatch. However unsure if this change should be included. The change is isolated in 5c0c0bdab9012a5f35dd4ab3a2847374578c8b9f . It seems more appropriate to actually test the MXBeans by default with no explicit gc, but I am open reverting this part.
The plan is to also backport this to 21 to improve the testing until release. The changes here should fall under `P1–P5 doc/test changes`
Running tests in Oracle CI. (tier1-tier5)
Verified that both `ZGenerational` and `ZSinglegen` tests get run in GHA.
Running tests in builds with `--disable-jvm-feature-zgc` to verify no regression.
-------------
Commit messages:
- MemoryTest.java run when not explicit
- Add vm.gc.{ZGenerational,ZSinglegen} to jtreg
Changes: https://git.openjdk.org/jdk/pull/14509/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14509&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8310187
Stats: 618 lines in 70 files changed: 447 ins; 5 del; 166 mod
Patch: https://git.openjdk.org/jdk/pull/14509.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/14509/head:pull/14509
PR: https://git.openjdk.org/jdk/pull/14509
More information about the hotspot-dev
mailing list