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

Yang Zhang (Arm Technology China) Yang.Zhang at arm.com
Fri Nov 15 03:35:54 UTC 2019


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



More information about the hotspot-compiler-dev mailing list