RFR(S) 8222582: [TESTBUG] AbstractMethodErrorTest.java fails with "did not test both cases (interpreted and compiled)."

Harold Seigel harold.seigel at oracle.com
Fri Jul 24 12:20:32 UTC 2020


Thanks David for taking a close look at this!

Harold

On 7/23/2020 7:25 PM, David Holmes wrote:
> On 24/07/2020 6:09 am, Harold Seigel wrote:
>> Hi David,
>>
>> The test achieves its goal of running under the interpreter and 
>> compiler by running with "vm.compMode=Xmixed".
>
> Okay .. and that precludes Xcomp as well.
>
>> The test fails unless both the interpreter and JIT compiled code 
>> generate AbstractMethodError exceptions. I ran the test in tiers 1-5 
>> without it failing.  So, at least for those test runs, the test 
>> achieved its goal of running under both the compiler and interpreter.
>>
>> Perhaps the purpose of "vm.opt.TieredStopAtLevel==4" is to specify 
>> the tiered behavior if TieredCompiliation is specified?
>
> Not clear - especially with the explicit WB compilation. This is one 
> complex test! :)
>
> Sorry to belabour what should be a trivial fix. As long as it works 
> without Graal and now excludes Graal, it is good to go.
>
> Thanks,
> David
> -----
>
>> Thanks, Harold
>>
>> On 7/23/2020 9:51 AM, David Holmes wrote:
>>> Hi Harold,
>>>
>>> On 23/07/2020 11:22 pm, Harold Seigel wrote:
>>>> Hi David,
>>>>
>>>> Thanks for looking at this.
>>>>
>>>> The existing @requires for test AbstractMethodErrorTest.java 
>>>> contained this clause:
>>>>
>>>>     (!vm.graal.enabled | vm.opt.TieredCompilation == true)
>>>>
>>>> This clause evaluated to TRUE if either Graal was disabled or 
>>>> vm.opt.TieredCompilation was true.
>>>
>>> Okay so this claimed the test was okay with Graal as long as tiered 
>>> was enabled but ...
>>>
>>>> Since now Graal is always disabled, this clause would always be TRUE,
>>>
>>> ... we decided no Graal under any conditions ... okay ...
>>>
>>>> regardless of the value of vm.opt.TieredCompilation.  There is not
>>>> requirement that tiered compilation be enabled for this test.
>>>
>>> ... but if tiered is not enabled then what is the significance of 
>>> "vm.opt.TieredStopAtLevel==4" ?
>>>
>>> Sorry but this is one of the most complex and obscure @requires 
>>> conditions that I've seen. And I don't see how it achieves the goal 
>>> of running under the interpreter and compiler (per the synopsis)?
>>>
>>> Thanks,
>>> David
>>>
>>>> Thanks, Harold
>>>>
>>>> On 7/22/2020 11:00 PM, David Holmes wrote:
>>>>> Hi Harold,
>>>>>
>>>>> On 23/07/2020 8:05 am, Harold Seigel wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review this small fix to avoid running test 
>>>>>> AbstractMethodErrorTest.java with Graal and remove it from the 
>>>>>> ProblemList.
>>>>>>
>>>>>> Open Webrev: 
>>>>>> http://cr.openjdk.java.net/~hseigel/bug_8222582/webrev/index.html
>>>>>
>>>>> You seem to have lost the requirement that tiered compilation be 
>>>>> enabled. ??
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8222582
>>>>>>
>>>>>> The change was tested by using mach5 testing and checking that 
>>>>>> the test was not run in tier*-graal tasks but was run in 
>>>>>> non-graal tasks.
>>>>>>
>>>>>> Thanks, Harold
>>>>>>


More information about the hotspot-runtime-dev mailing list