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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Mar 15 10:32:38 UTC 2018


Well, the Process api is, in the end, a test framework inside the test framework ...
I think the Process api is useful if your test can not be implemented as a 
pure java program, like when you want to parse the output of the VM.

In my case, the test is a pure Java application and as such should be
runnable by just jtreg means.
Nobody can foresee problems with (arbitrary) flags passed by some tester to 
the tested VMs.
I think
  1. there should be a well defined set of flags the tests must cope with
  2. for these well defined sets there should be jtreg means to specify
     the behavior of the test
This is already solved quite well for compModes Xint, Xcomp and Xmixed.
There should be similar for C1, C2, Graal and maybe GCs?

Best regards,
  Goetz.





> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 15. März 2018 10:36
> To: Thomas Stüfe <thomas.stuefe at gmail.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>
> Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(S): 8199532: AbstractMethodErrorTest.java test failed with -
> Xcomp
> 
> 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