RFR: 8231954: [TESTBUG] Test compiler/codegen/TestCharVect2.java only works with server VMs.

[Igor Ignatev]

LGTM

— Igor

> On Nov 14, 2019, at 3:22 AM, christoph.goettschkes at microdoc.com wrote:
> 
> Thanks for your feedback, this resolves my concerns and I am happy with 
> the solution. I integrated the suggestions from Vladimir, here is the 
> latest webrev:
> 
> https://cr.openjdk.java.net/~cgo/8231954/webrev.02/
> 
> I re-tested and it works as expected.
> Please give your consent if this is fine for you as well.
> 
> -- Christoph
> 
> Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote on 2019-11-13 20:32:18:
> 
>> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>> To: Igor Ignatyev <igor.ignatyev at oracle.com>, 
> christoph.goettschkes at microdoc.com
>> Cc: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>> Date: 2019-11-13 20:32
>> Subject: Re: RFR: 8231954: [TESTBUG] Test compiler/codegen/
>> TestCharVect2.java only works with server VMs.
>> 
>>> On 11/13/19 11:11 AM, Igor Ignatyev wrote:
>>> @Christoph,
>>> 
>>> webrev.01 looks good to me.
>>> I always thought that jvmci feature can be built only when compiler2 
>> feature is enabled, however src/hotspot/share/jvmci/jvmci_globals.hpp 
>> suggests that jvmci can be used w/o compiler2; I don't think we have 
>> ever build/test, let alone support, this configuration.
>>> 
>>> @Vladimir,
>>> did/do we plan to support compiler1 + jvmci w/o compiler2 
> configuration?
>> 
>> Yes. It could be configuration when we start looking on replacing C1 
>> with Graal. I think several people were interested 
>> in "Client VM" like configuration.
>> Also Server configuration without C2 (with Graal or other jvmci 
>> compiler) which would be out configuration in a future.
>> 
>> But I would prefer to be more explicit in these changes:
>> 
>> @requires vm.compiler2.enabled | vm.graal.enabled
>> 
>> Thanks,
>> Vladimir
>> 
>>> 
>>> Thanks,
>>> -- Igor
>>> 
>>>> On Nov 13, 2019, at 4:42 AM, christoph.goettschkes at microdoc.com 
> wrote:
>>>> 
>>>> Hi Igor,
>>>> 
>>>> thanks for your explanation.
>>>> 
>>>> Igor Ignatyev <igor.ignatyev at oracle.com> wrote on 2019-11-12 
> 20:40:46:
>>>> 
>>>>> we are trying to get rid of IgnoreUnrecognizedVMOptions in our 
> tests, as
>>>>> in most cases, it causes wasted compute time (as in this test) and 
> can
>>>>> also lead to wrong/deprecated/deleted flags sneaking into the 
> testbase
>>>> 
>>>> Agreed. I also wanted to discuss this, since I think that your 
> solution
>>>> is better than mine, but at the same time, I saw possible problems 
> with
>>>> it, see below.
>>>> 
>>>>> as '@requires vm.flavor == "server"' filters configurations based vm
>>>>> build type, it will still allow execution on JVM w/ JVMCI and when 
> JVMCI
>>>>> compiler is selected, as it will still be Server VM build. so, in a
>>>>> sense, the test will be w/ JVMCI in the same way as w/ your 
> approach.
>>>> 
>>>> My concern is not about server VMs with JVMCI, but client VMs with 
> JVMCI
>>>> enabled. Is this a valid configuration? The MaxVectorSize option is
>>>> defined in [1] as well as in [2], so for me it looks like 
> MaxVectorSize
>>>> can be used for any VM variant as long as JVMCI is enabled. The
>>>> configure script also states that both compilers are possible (if you
>>>> configure with --with-jvm-features='jvmci'):
>>>> 
>>>> configure: error: Specified JVM feature 'jvmci' requires feature
>>>> 'compiler2' or 'compiler1'
>>>> 
>>>> Should maybe the requires tag "vm.jvmci" be used as well, like:
>>>> 
>>>>    @requires vm.flavor == "server" | vm.jvmci
>>>> 
>>>>> this is the known limitation of jtreg/@requires, and our current way 
> to
>>>>> workaround it is to split a test description based on @requires 
> values
>>>> 
>>>> Yes, if the @requires tag is used, splitting up the test looks like a 
> good
>>>> idea. I didn't know that it is possible to have multiple test 
> descriptions
>>>> in one test file.
>>>> 
>>>> I created a new webrev with the new ideas:
>>>> 
>>>> https://cr.openjdk.java.net/~cgo/8231954/webrev.01/
>>>> 
>>>> I tested with an amd64 client and server VM and it looks good. I am
>>>> currently unable to build a client VM with JVMCI enabled, hence no 
> test
>>>> for that yet. I get compile errors and as soon as I resolve those,
>>>> runtime errors occur. Before I look into that, I would like to know 
> if
>>>> client VMs with JVMCI enabled are supported or not.
>>>> 
>>>> Thanks,
>>>> Christoph
>>>> 
>>>> [1]
>>>> https://hg.openjdk.java.net/jdk/jdk/file/dc1899bb84c0/src/hotspot/
>> share/opto/c2_globals.hpp
>>>> 
>>>> [2]
>>>> https://hg.openjdk.java.net/jdk/jdk/file/dc1899bb84c0/src/hotspot/
>> share/jvmci/jvmci_globals.hpp
>>>> 
>>> 
>> 
>