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

Leo Korinth lkorinth at openjdk.java.net
Tue Jun 29 10:29:59 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.

Marked as reviewed by lkorinth (Committer).

test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationTools.java line 73:

> 71:         }
> 72:     }
> 73: 

I think it would be good to parse the gc string. Otherwise it might be easy to make a spelling mistake or add another argument (before) to the driver without realizing the error.

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

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



More information about the hotspot-gc-dev mailing list