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

Tobias Hartmann tobias.hartmann at oracle.com
Fri Oct 3 09:22:31 UTC 2014


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


[1] OSR compiled methods:

[2] https://bugs.openjdk.java.net/browse/JDK-8030976

More information about the hotspot-compiler-dev mailing list