RFR/RFC 8231503: [TESTBUG] compiler/{jvmci, aot} tests should not run with GCs that do not support JVMCI/AOT

Dmitry Samersoff dms at samersoff.net
Tue Oct 1 11:01:16 UTC 2019


Aleksey,

> I don't think new flag wins us anything? I believe most of the tests
> would then be:
>  @requires vm.aot & vm.aot_compatible_gc

This combination gives to a Maintainer a clear point of what should be
checked if the test doesn't run.

-Dmitry


On 30.09.19 11:27, Aleksey Shipilev wrote:
> On 9/30/19 10:22 AM, Dmitry Samersoff wrote:
>> Updating all tests with long @require (and maintain it in the future)
>> can be a painful task.
>>
>> One of possible option is to introduce vm.aot_compatible_gc and update
>> @require to use this new flag.
> 
> I don't think new flag wins us anything? I believe most of the tests would then be:
>  @requires vm.aot & vm.aot_compatible_gc
> 
> ...which suggests we should be "just" setting the vm.aot properly?
> 
>> But, if you finally go to the simple way that is shown in candidate
>> webrev, please factor out GC selection logic into a separate function,
>> to have it in one place.
> 
> I thought about it when doing the candidate patch. Are we sure that GC support of AOT and JVMCI is
> symmetrical? I.e. if GC supports JVMCI, is it guaranteed to support AOT, and vice versa? If not, the
> selection logic should remain separate.
> 


More information about the hotspot-compiler-dev mailing list