RFR(S): 8199532: AbstractMethodErrorTest.java test failed with -Xcomp
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Wed Mar 14 10:36:15 UTC 2018
Hi,
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="-Xcomp"
-javaoptions="-XX:-TieredCompilation"
-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,
Goetz.
> -----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