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

Fri Nov 15 10:40:21 UTC 2019

Hi Yang,

I don't see a problem with applying the same idea to other tests to get 
rid of the IgnoreUnrecognizedVMOptions option.

> Ps. For [3],  it locates in c2 directory. So I'm not sure whether they 
> will be excluded in jtreg test with client mode.

No, I don't think so. Those tests are not excluded automatically by jtreg. 
Running

    $ make test TEST=hotspot_all JTREG='OPTIONS=-l'

Lists all tests in the c2 directory:

...
compiler/c2/cr6340864/TestByteVect.java
compiler/c2/cr6340864/TestDoubleVect.java
...

The directory "cr6340864" is however excluded from the hotspot tier1 test 
group.

One thing I noticed: some of the tests use other flags, which are only 
supported by the C2 compiler, like TestNaNVector.java [1]. The flag "
OptimizeFill" is only present in c2_globals.hpp [4] and not in 
jvmci_globals.hpp [5], so the @requires tag should look different. Maybe 
for [1], we should add another @run tag with no -XX arguments whatsoever?

-- Christoph

[1]
https://hg.openjdk.java.net/jdk/jdk/file/4dbdb7a8fa75/test/hotspot/jtreg/compiler/vectorization/TestNaNVector.java

[4]
https://hg.openjdk.java.net/jdk/jdk/file/6f42d2a19117/src/hotspot/share/opto/c2_globals.hpp

[5]
https://hg.openjdk.java.net/jdk/jdk/file/6f42d2a19117/src/hotspot/share/jvmci/jvmci_globals.hpp

"Yang Zhang (Arm Technology China)" <Yang.Zhang at arm.com> wrote on 
2019-11-15 04:35:54:

> From: "Yang Zhang (Arm Technology China)" <Yang.Zhang at arm.com>
> To: "christoph.goettschkes at microdoc.com" 
> <christoph.goettschkes at microdoc.com>, "vladimir.kozlov at oracle.com" 
> <vladimir.kozlov at oracle.com>, "igor.ignatyev at oracle.com" 
> <igor.ignatyev at oracle.com>
> Cc: "hotspot-compiler-dev at openjdk.java.net" <hotspot-compiler-
> dev at openjdk.java.net>
> Date: 2019-11-15 04:36
> Subject: RE: RFR: 8231954: [TESTBUG] Test compiler/codegen/
> TestCharVect2.java only works with server VMs.
> 
> Hi Christoph, Igor, Vladimir,
> 
> Thanks very much for your fix. After discussion, we have got a better 
> solution for this issue. Do we need to change the following files in 
> which MaxVectorSize option is used?
> 
> [1] https://hg.openjdk.java.net/jdk/jdk/file/4dbdb7a8fa75/test/hotspot/
> jtreg/compiler/vectorization/TestNaNVector.java
> [2] https://hg.openjdk.java.net/jdk/jdk/file/4dbdb7a8fa75/test/hotspot/
> jtreg/compiler/vectorization/TestPopCountVector.java
> [3] https://hg.openjdk.java.net/jdk/jdk/file/4dbdb7a8fa75/test/hotspot/
> jtreg/compiler/c2/cr6340864
> 
> Ps. For [3],  it locates in c2 directory. So I'm not sure whether they 
> will be excluded in jtreg test with client mode.
> 
> Regards
> Yang
> 
> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of 
christoph.goettschkes at microdoc.com
> Sent: Thursday, November 14, 2019 7:21 PM
> To: vladimir.kozlov at oracle.com; igor.ignatyev at oracle.com
> Cc: hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR: 8231954: [TESTBUG] Test compiler/codegen/
> TestCharVect2.java only works with server VMs.
> 
> 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
> > >>
> > >
> >
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy 
> the information in any medium. Thank you.
> 