RFR(S) 8222582: [TESTBUG] AbstractMethodErrorTest.java fails with "did not test both cases (interpreted and compiled)."
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Fri Jul 24 12:30:36 UTC 2020
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