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

David Holmes david.holmes at oracle.com
Thu Jul 23 13:51:51 UTC 2020

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, 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