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

[Tobias Hartmann]

Hi Vladimir,

thanks for the review.

On 03.10.2014 19:20, Vladimir Kozlov wrote:
> Nightly runs done with -Xcomp. Make sure your changes still work.

I did some more testing on JPRT with -Xcomp and also with 
-XX:-TieredCompilation. No failures (the results are linked in the comment 
section). Most tests explicitly specify '-Xmixed'.

> 200 for tiered may be too high. C1 compilation triggered before that,
> please check.

Yes, that's intended. After some more testing I even increased the value to 2000 
to make sure that the loop exit branch probability is high enough and we never 
add an uncommon trap. If the method is compiled during warmup the following 
deoptimization ensures that we throw away the compiled version and an OSR 
compilation is triggered:

  551             // Make sure method is not (yet) compiled
  552             deoptimize(m);

I also added code to wait for a potential background compilation (see 
'Helper.deoptimize') because the method may still be in the compile queue.

The fixed tests pass on all platforms with and without -Xcomp.

New webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.01/

Thanks,
Tobias

>
> Thanks,
> Vladimir
>
> On 10/3/14 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