RFR: 8269032: Stringdedup tests are failing if the ergonomically select GC does not support it

Kim Barrett kbarrett at openjdk.java.net
Sun Jun 27 01:53:20 UTC 2021

Please review this change to the string deduplication tests' handling of an
ergonomically chosen GC.  They were assuming G1 would be chosen in that
case, but that's wrong of course.  The test machine might not be a server
class machine, or G1 might not be included in the build.

Each test now has a second test declaration comment for handling the case
where no GC is specified by the jtreg invocation.  This second declaration
will force the use of G1 by the test if G1 is supported by the VM.

I looked into trying to be more clever and selecting a different GC if G1 is
not supported by the VM, but that ended up making the tests a lot more
messy, and doesn't seem like that important a use-case at this time.  A
better long-term solution would be to make all the GCs (except Epsilon)
support string deduplication, so we don't care which GC gets ergonomically
chosen.  But that's not happening today.

Ran the string deduplication tests with various configurations: (1)
explicitly use G1 (2) no explicit GC, (3) no explicit GC with


Commit messages:
 - explicitly use G1 for ergonomic case

Changes: https://git.openjdk.java.net/jdk/pull/4603/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4603&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269032
  Stats: 101 lines in 7 files changed: 95 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4603.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4603/head:pull/4603

PR: https://git.openjdk.java.net/jdk/pull/4603

More information about the hotspot-gc-dev mailing list