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

Per Liden pliden at openjdk.java.net
Tue Jun 29 11:17:01 UTC 2021

On Sun, 27 Jun 2021 01:38:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> 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.
> Testing:
> Ran the string deduplication tests with various configurations: (1)
> explicitly use G1 (2) no explicit GC, (3) no explicit GC with
> -XX:+NeverActAsServerClassMachine.

Also, I think `-XX:+NeverActAsServerClassMachine` is a bit of an special case or anomaly. It's the only option that influences which GC is ergonomically selected, and I'm not sure it should even do that. Rather that trying to dance around it here, I would suggest that we no longer allow that option to influence which GC is selected.


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

More information about the hotspot-gc-dev mailing list