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