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

[christoph.goettschkes at microdoc.com]

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