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

[Tobias Hartmann]

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
>