RFR: 8269032: Stringdedup tests are failing if the ergonomically select GC does not support it
kbarrett at openjdk.java.net
Wed Jun 30 06:10:06 UTC 2021
On Tue, 29 Jun 2021 11:02:08 GMT, Per Liden <pliden 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.
>> Ran the string deduplication tests with various configurations: (1)
>> explicitly use G1 (2) no explicit GC, (3) no explicit GC with
> test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationAgeThreshold.java line 30:
>> 28: * @summary Test string deduplication age threshold
>> 29: * @bug 8029075
>> 30: * @requires vm.gc == "G1" | vm.gc == "Shenandoah"
> I think this should be `@requires vm.gc.G1` and it should pass `-XX:+UseG1GC`to the test, which it appends to the list of arguments for the JVM that will be spawned.
> 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.
I think you missed the point. I'm pretty sure the original report arose
because of running these tests on a non-server machine. I don't have ready
access to such a machine, but by using that option I was able to fake things
enough to feel confident these tests would now run on such.
I think the main problem with -XX:+NeverActAsServerClassMachine (and the
associated -XX:+AlwaysActAsServerClassMachine) is that they are product
options rather than diagnostic options. That may be because they've been
around "forever" and nobody has taken the time to change them.
More information about the hotspot-gc-dev