RFR(S) [15] : 8249000 : vm.gc.X should take selected JIT into account

[Vladimir Kozlov]

Nice clean up, Igor

test/hotspot/jtreg/gc/stress/TestReclaimStringsLeaksMemory.java

Do we even can have vm.gc=="null" based on code in VMProps.java? At least some GC should be selected ergonomically even 
if non is specified on command line.

- * @requires vm.gc=="null" & !vm.graal.enabled & !vm.debug
+ * @requires vm.gc == "null"
+ * @requires !vm.debug


test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java

Does next combination of @requires ever work? I thought such sequence means 'AND' operation on all such conditions.

   * @requires vm.gc.Z
   * @requires vm.gc.Serial
   * @requires vm.gc == null


Thanks,
Vladimir

On 7/7/20 5:38 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8249000/webrev.00/
>> 241 lines changed: 34 ins; 5 del; 202 mod;
> 
> 
> Hi all,
> 
> could you please review the patch which modifies requires/VMProps to set vm.gc.X to false if Graal is selected and X GC isn't supported by Graal?
> 
> the patch also replaces @requires similar to `vm.gc.X & !vm.graal.enabled` w/ `vm.gc.X` where it's applicable.
> 
> from JBS:
>> not all GCs are supported by Graal JIT, which leads to failures like JDK-8247527 and boilerplate fixes like replacing all `@requires vm.gc.Z` w/ `@requires vm.gc.Z & !vm.graal.enabled`.
>>
>> as vm.gc.X means that X GC can be selected, it would be more natural, less surprising, and much more clear to have it true if the selected JIT supports the said X GC.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev/8249000/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8249000
> testing: test/hotspot/jtreg/{gc,compiler,runtime,serviceability} on {linux,windows,macos}-x64 w/ and w/o Graal as JIT
> 
> Thanks,
> -- Igor
>