[9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled

[Igor Ignatyev]

Dean/Tobias,

I've filed an RFE for it -- 
https://bugs.openjdk.java.net/browse/JDK-8059923.

Igor

On 10/08/2014 11:43 AM, Tobias Hartmann wrote:
> Hi Dean,
>
> thanks for the feedback.
>
> On 03.10.2014 20:07, dean long wrote:
>> In the future, it might be useful for the whitebox interface to return a
>> compilation count for a method.
>> That way we can query "is or was compiled" vs. "is currently compiled".
>
> Yes that would be useful but there are some tests that need a compiled
> version of the method. For example, compiler.whitebox.GetNMethodTest.
>
> Best,
> Tobias
>
>>
>> dl
>>
>> On 10/3/2014 2:22 AM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> please review the following patch.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046268
>>> Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/
>>>
>>> == Problem ==
>>> The whitebox tests assume that after the invocation of
>>> 'CompilerWhiteBoxTest.compile()' the method is always compiled and
>>> 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR
>>> compilations [1] this is does not hold. For example, in case of the
>>> following events:
>>>
>>> 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile
>>> 'SimpleTestCase.Helper.osrMethod()'.
>>> 2) OSR compilation is performed at level 4. An uncommon trap is added
>>> after the loop because profiling never reached that point. Execution
>>> continues with the OSR version.
>>> 3) Deoptimization is triggered because the loop finishes (reason:
>>> 'unstable if'). The OSR nmethod is made non-entrant and removed from
>>> the OSR list (see 'nmethod::invalidate_osr_method').
>>> 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the
>>> method is OSR compiled. Because the OSR nmethod was removed from the
>>> list, check compiled returns false (see WB_IsMethodCompiled).
>>>
>>> This was caused by the fix for JDK-8030976 [2] because we now trust
>>> the profile information more and add uncommon traps to untaken paths.
>>> In this case we add an uncommon trap after the loop exit:
>>>
>>> private int osrMethod() {
>>>   int result = 0;
>>>   for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) {
>>>     result += method();
>>>   }
>>>   return result;
>>> }
>>>
>>> == Solution ==
>>> I added code to 'warm up' the methods before triggering OSR
>>> compilation by executing them a limited number of times. Like this,
>>> the profile information marks the loop exit as taken and we don't add
>>> an uncommon trap.
>>>
>>> == Testing ==
>>> - Executed failing tests on JPRT
>>>
>>> Thanks,
>>> Tobias
>>>
>>>
>>> [1] OSR compiled methods:
>>> compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR
>>> compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD
>>> compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC
>>>
>>> [2] https://bugs.openjdk.java.net/browse/JDK-8030976
>>