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

christoph.goettschkes at microdoc.com christoph.goettschkes at microdoc.com
Wed Nov 13 12:42:58 UTC 2019


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