RFR(S): 8199532: AbstractMethodErrorTest.java test failed with -Xcomp
David Holmes
david.holmes at oracle.com
Thu Mar 15 09:35:48 UTC 2018
On 15/03/2018 5:47 PM, Thomas Stüfe wrote:
> On Thu, Mar 15, 2018 at 8:36 AM, Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com <mailto:goetz.lindenmaier at sap.com>> wrote:
>
> Hi,
>
> yes, there should be a simplification of that statement, like
> @requires noExternalVMOptions
> which makes jtreg drop all options passed by -javaoptions
> or skip the test if any are set.
> It could also be a flavor of othervm, maybe purevm ...
>
> Best regards,
> Goetz.
>
>
> But isn't the problem with that approach that we may quietly drop the
> test and never really execute it without ever noticing?
Yes, requiring no options at all may be a little too broad. :) And
unfortunately we don't have a way to say "ignore any options relating to
XXX" for XXX = compiler, gc, etc.
> I like Davids proposal. Which btw is what we at SAP do for a lot of our
> tests. We also have a infrastructure library which makes spawning VM
> processes and analysing its output very easy.
The OpenJDK testlibrary has similar utilities. Of course the main goal
of the VM launching utilities is to pass on the jtreg options rather
than exclude them - but both are possible.
Cheers,
David
> ..Thomas
>
>
> > -----Original Message-----
> > From: David Holmes [mailto:david.holmes at oracle.com <mailto:david.holmes at oracle.com>]
> > Sent: Donnerstag, 15. März 2018 02:45
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com
> <mailto:goetz.lindenmaier at sap.com>>; 'Vladimir Kozlov'
> > <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>;
> hotspot-runtime-dev at openjdk.java.net
> <mailto:hotspot-runtime-dev at openjdk.java.net>
> > Subject: Re: RFR(S): 8199532: AbstractMethodErrorTest.java test
> failed with -
> > Xcomp
> >
> > For the record I think what was done here to get this to run okay is
> > truly awful. I think this is the wrong approach for dealing with
> tests
> > that need to explicitly test interpreter behaviour or JIT
> behaviour. If
> > the incoming jtreg flags can disrupt the test then we need to run the
> > test in a way that is isolated from those flags e.g by directly
> exec'ing
> > a VM with the right flags -Xint, -Xcomp etc.
> >
> > David
> >
> > On 15/03/2018 6:30 AM, Lindenmaier, Goetz wrote:
> > > Hi Vladimir,
> > >
> > > Thanks for pushing!
> > > And sorry for causing the trouble.
> > >
> > > Best regards,
> > > Goetz.
> > >
> > >> -----Original Message-----
> > >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com
> <mailto:vladimir.kozlov at oracle.com>]
> > >> Sent: Wednesday, March 14, 2018 7:04 PM
> > >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com
> <mailto:goetz.lindenmaier at sap.com>>; David Holmes
> > >> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>>;
> hotspot-runtime-dev at openjdk.java.net
> <mailto:hotspot-runtime-dev at openjdk.java.net>
> > >> Subject: Re: RFR(S): 8199532: AbstractMethodErrorTest.java
> test failed
> > with -
> > >> Xcomp
> > >>
> > >> Good. I added webrev to bug report.
> > >> I will let you know when testing finished.
> > >>
> > >> Vladimir
> > >>
> > >> On 3/14/18 10:58 AM, Lindenmaier, Goetz wrote:
> > >>> Hi Vladimir,
> > >>>
> > >>> I added the changes you proposed to a new webrev:
> > >>> http://cr.openjdk.java.net/~goetz/wr18/8199532-
> <http://cr.openjdk.java.net/~goetz/wr18/8199532->
> > >> fixAmeExMsg/webrev.03/
> > >>>
> > >>> I also added all the flags to the
> IncompatibleClassChangeErrorTest.java.
> > >>> It needs as least compMode==Xmixed, it fails with Xint. It
> passes with -
> > >> Xcomp etc.
> > >>> If you think it's not necessary I'll just remove it again.
> > >>>
> > >>> Best regards,
> > >>> Goetz.
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com
> <mailto:vladimir.kozlov at oracle.com>]
> > >>>> Sent: Wednesday, March 14, 2018 5:51 PM
> > >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com
> <mailto:goetz.lindenmaier at sap.com>>; David Holmes
> > >>>> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>>;
> hotspot-runtime-dev at openjdk.java.net
> <mailto:hotspot-runtime-dev at openjdk.java.net>
> > >>>> Subject: Re: RFR(S): 8199532: AbstractMethodErrorTest.java
> test failed
> > >> with -
> > >>>> Xcomp
> > >>>>
> > >>>> Thank you, Goetz
> > >>>>
> > >>>> You need additional check TieredStopAtLevel == null in @require
> > >>>> otherwise it does not execute even without any external flags:
> > >>>>
> > >>>> - * @requires !(os.arch=="arm")
> > >>>> + * @requires !(os.arch=="arm") & vm.flavor == "server" &
> > >>>> !vm.emulatedClient & vm.compMode=="Xmixed" &
> > (!vm.graal.enabled |
> > >>>> vm.opt.TieredCompilation == true) & (vm.opt.TieredStopAtLevel ==
> > null |
> > >>>> vm.opt.TieredStopAtLevel==4)
> > >>>>
> > >>>> I also tested with Graal JIT and it passed with above
> changes but it
> > >>>> require Tiered switched ON otherwise it will timeout (since
> Graal run in
> > >>>> Interpreter until it compiles itself). That is why there is
> additional
> > >>>> Graal's conditions in @require.
> > >>>>
> > >>>> But it is not enough when Tiered is off. For that you need
> to increase
> > >>>> iterations (10000 is at the border of triggering C2
> compilation) or
> > >>>> better add -XX:CompileThreshold=1000 flag to @run command - it
> > would
> > >>>> require less time to run test:
> > >>>>
> > >>>> - * -XX:-BackgroundCompilation -XX:-Inline
> > >>>> + * -XX:CompileThreshold=1000
> > >>>> -XX:-BackgroundCompilation -XX:-Inline
> > >>>>
> > >>>> I started testing with this changes
> > >>>>
> > >>>> Thanks,
> > >>>> Vladimir
> > >>>>
> > >>>> On 3/14/18 7:53 AM, Lindenmaier, Goetz wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> this webrev adds @requires statements so that the test is
> skipped in
> > the
> > >>>>> test runs below. With C1 the explicit compilation won't work,
> > anyways.
> > >>>>>
> > >>>>> Please review:
> > >>>>> http://cr.openjdk.java.net/~goetz/wr18/8199532-
> <http://cr.openjdk.java.net/~goetz/wr18/8199532->
> > >>>> fixAmeExMsg/webrev.02/
> > >>>>>
> > >>>>> Best regards,
> > >>>>> Goetz.
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> <mailto:hotspot-runtime-dev->
> > >>>>>> bounces at openjdk.java.net
> <mailto:bounces at openjdk.java.net>] On Behalf Of David Holmes
> > >>>>>> Sent: Mittwoch, 14. März 2018 01:10
> > >>>>>> To: Vladimir Kozlov <vladimir.kozlov at oracle.com
> <mailto:vladimir.kozlov at oracle.com>>; hotspot-runtime-
> > >>>>>> dev at openjdk.java.net <mailto:dev at openjdk.java.net>
> > >>>>>> Subject: Re: RFR(S): 8199532: AbstractMethodErrorTest.java
> test
> > failed
> > >>>> with -
> > >>>>>> Xcomp
> > >>>>>>
> > >>>>>> On 14/03/2018 7:41 AM, Vladimir Kozlov wrote:
> > >>>>>>> Thank you, Goetz
> > >>>>>>>
> > >>>>>>> -Xcomp passed now.
> > >>>>>>>
> > >>>>>>> I tried other flags we use for testing. And it failed
> when Tiered is
> > >>>>>>> off: -XX:-TieredCompilation or -XX:+TieredCompilation
> > >>>>>>> -XX:TieredStopAtLevel=1.
> > >>>>>>>
> > >>>>>>> Stupid question. Why we have different messages for
> compiler and
> > >>>>>>> interpreter? The problem is the same.
> > >>>>>>
> > >>>>>> The difference is whether information on the receiver class is
> > available.
> > >>>>>>
> > >>>>>> David
> > >>>>>>
> > >>>>>>> -Xcomp flag also set -Xbatch flag so you don't need it in
> comment:
> > >>>>>>>
> > >>>>>>> + // Seen if test started with -Xcomp -Xbatch:
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> Vladimir
> > >>>>>>>
> > >>>>>>> On 3/13/18 2:14 PM, 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-
> <http://cr.openjdk.java.net/~goetz/wr18/8199532->
> > >>>>>> fixAmeExMsg/webrev.01/
> > >>>>>>>>
> > >>>>>>>> Best regards,
> > >>>>>>>> Goetz.
> > >>>>>>>>
>
>
More information about the hotspot-runtime-dev
mailing list