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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Mar 15 07:36:22 UTC 2018


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.


> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Donnerstag, 15. März 2018 02:45
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; '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
> 
> 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]
> >> Sent: Wednesday, March 14, 2018 7:04 PM
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; David Holmes
> >> <david.holmes at oracle.com>; 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-
> >> 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]
> >>>> Sent: Wednesday, March 14, 2018 5:51 PM
> >>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; David Holmes
> >>>> <david.holmes at oracle.com>; 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-
> >>>> fixAmeExMsg/webrev.02/
> >>>>>
> >>>>> Best regards,
> >>>>>      Goetz.
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> >>>>>> 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>; hotspot-runtime-
> >>>>>> 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-
> >>>>>> fixAmeExMsg/webrev.01/
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>>       Goetz.
> >>>>>>>>


More information about the hotspot-runtime-dev mailing list