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

Kim Barrett kbarrett at openjdk.java.net
Thu Jul 15 07:04:15 UTC 2021


On Wed, 30 Jun 2021 12:34:23 GMT, Per Liden <pliden at openjdk.org> wrote:

>> That's an approach that I had looked at but decided not to take.
>> 
>> It involves having a near duplicated `@test` block for each GC that supports
>> deduplication, at least until they all do (other than Epsilon).
>> 
>> I think it wastes testing resources. Each testing configuration that allows
>> ergonomic GC selection will run these tests for every supporting and
>> included GC.  Individually it's not terrible, but this sort of thing adds up.
>
> I don't think that's a problem you should attempt solve in this PR. It's a much wider problem, affects many more tests and I don't think there's necessarily consensus on what should happen if you run a test and don't explicitly set a GC. At the moment, tests in this category typically run with all GCs, and that's so far been what to expect. I suggest we continue to follow our current model for stringdedup tests until there's consensus on what a new model should look like, and only then start to move tests in a new direction. Even if the current model is sub-optimal and messy, introducing a new type of behavior for these tests seems to just add to the mess, and there's at least some value in having tests behave the same way.
> 
> If we want to move in the direction where running a test without specifying a GC will run it once with the ergonomically selected GC, then it might be that simply altering the meaning of `vm.gc.XXX` to "XXX is supported and selected (explicitly or ergonomically)" is enough. Of course, it's tricky to clearly see that all use cases are covered, so something like this will need more careful investigation.

After thinking about it for a while, I've decided to go with Per's suggestion. I don't really like the duplication of `@test` blocks, but I don't like any of the other options either.

Tested by locally (linux-x64) configuring with Shenandoah included and running the gc/stringdedup tests with
(1) no additional options,
(2) -XX:+NeverActAsServerClassMachine,
(3) -XX:+UseG1GC,
(4) -XX:+UseShenandoahGC
and verifying the expected tests were run.

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

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


More information about the hotspot-gc-dev mailing list