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

[Vladimir Kozlov]

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
>>
>