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

[Per Liden]

On Wed, 30 Jun 2021 11:39:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Sorry, let me be more specific. I was proposing you do this (in all these tests):
>> 
>> ```diff --git a/test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationFullGC.java b/test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationFullGC.java
>> index 66d58a6e580..6a358ae54f3 100644
>> --- a/test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationFullGC.java
>> +++ b/test/hotspot/jtreg/gc/stringdedup/TestStringDeduplicationFullGC.java
>> @@ -27,26 +27,26 @@ package gc.stringdedup;
>>   * @test TestStringDeduplicationFullGC
>>   * @summary Test string deduplication during full GC
>>   * @bug 8029075
>> - * @requires vm.gc == "G1" | vm.gc == "Shenandoah"
>> + * @requires vm.gc.G1
>>   * @library /test/lib
>>   * @library /
>>   * @modules java.base/jdk.internal.misc:open
>>   * @modules java.base/java.lang:open
>>   *          java.management
>> - * @run driver gc.stringdedup.TestStringDeduplicationFullGC
>> + * @run driver gc.stringdedup.TestStringDeduplicationFullGC G1
>>   */
>>  
>>  /*
>>   * @test TestStringDeduplicationFullGC
>>   * @summary Test string deduplication during full GC
>>   * @bug 8029075
>> - * @requires vm.gc == "null" & vm.gc.G1
>> + * @requires vm.gc.Shenandoah
>>   * @library /test/lib
>>   * @library /
>>   * @modules java.base/jdk.internal.misc:open
>>   * @modules java.base/java.lang:open
>>   *          java.management
>> - * @run driver gc.stringdedup.TestStringDeduplicationFullGC G1
>> + * @run driver gc.stringdedup.TestStringDeduplicationFullGC Shenandoah
>>   */
>>  
>>  public class TestStringDeduplicationFullGC {
>
> 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.

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

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