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

[dean long]

Thanks Igor!

dl

On 10/8/2014 2:10 AM, Igor Ignatyev wrote:
> 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
>>>