RFR(S): 8199532: AbstractMethodErrorTest.java test failed with -Xcomp

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Wed Mar 14 10:36:15 UTC 2018


can you tell me how I exclude the "obscure modes"? 
As I don't know what kind of modes these are, I don't know
how to exclude them.  If I had known there are more tests
I would have verified those too.

Does @requires vm.compMode == Xmixed suffice?

If you tell me which targets you run with which flags, 
I can try to get them scheduled in our tests, too.

I assume you start jtreg with 
-javaoptions= "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"
are there more?  And which subsets do you run with these options?
Or can I somehow specify the compMode?  (I'll have a closer look
myself once I fixed the assertion :)).

Best regards,

> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Mittwoch, 14. März 2018 01:14
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(S): 8199532: AbstractMethodErrorTest.java test failed with -
> Xcomp
> Hi Goetz,
> On 14/03/2018 7:14 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > AbstractMethodErrorTest fails with -Xcomp because
> > other exception messages are printed if the error happens
> > in comiled code.
> > I hardened the test.
> > Please review:
> > http://cr.openjdk.java.net/~goetz/wr18/8199532-
> fixAmeExMsg/webrev.01/
> I expected to see a solution using @requires to exclude Xcomp or other
> obscure modes as Vladimir pointed out.
> I think when something like this is so sensitive to the compilation
> environment, that the test needs to maintain complete control. I'd be
> tempted to even simplify the test to expect to be run in either
> interpreted or compiled mode, exclude running the test at all if any
> compiler flags come in via jtreg, and then have explicit @run
> main/othervm for the different scenarios:
> - -Xint
> - -Xcomp
> - non-tiered
> ...
> Though execution time may be a factor.
> And apologies for not thinking about this enough during the review process.
> Thanks,
> David
> > Best regards,
> >    Goetz.
> >

More information about the hotspot-runtime-dev mailing list