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:32:13 UTC 2020


Thanks Coleen!

Harold

On 7/24/2020 8:30 AM, coleen.phillimore at oracle.com wrote:
>
> Looks good (although somewhat insane) to me.
> Coleen
>
> On 7/24/20 8:20 AM, Harold Seigel wrote:
>> 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