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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Mar 14 18:04:23 UTC 2018


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