[9] RFR(S): 8062169: Multiple OSR compilations issued for same bci

[Tobias Hartmann]

Hi,

please review the following fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8062169
Webrev: http://cr.openjdk.java.net/~thartmann/8062169/webrev.00/

Summary:
An existing OSR nmethod blocks OSR for the same method at other BCIs.

Problem:
The method 'triggerOSR' contains two loops to trigger OSR compilations. The
first loop triggers an OSR compilation at BCI 59 and comp level 4. While
executing the second loop an OSR compilation at BCI 89 and comp level 3 is
triggered [1]. We then check if the event led to a higher level OSR compilation
by checking if the 'highest_osr_comp_level()' is greater than the current
compilation level (in this case 0 since we are interpreting) and if so perform
an OSR [2]. The problem is that 'highest_osr_comp_level()' is independent of the
BCI and therefore returns 4 (because of the existing OSR nmethod at BCI 59). The
following lookup for an OSR nmethod at BCI 89 fails and no OSR is performed. The
interpreter continues executing the method until the backbranch event is
triggered again and we start right from the beginning. However, we do not issue
a new OSR compilation but fail to perform OSR with the existing OSR nmethod.
This repeats until we finally decide to OSR compile at level 4 (see log [3]).

With -Xcomp it's even worse because we issue a new compilation every time. This
is because a compilation at level 3 is requested but an in-queue update changes
it to level 2 (see 'AdvancedThresholdPolicy::select_task'). The next time the
compilation is requested we search for existing level 3 compilations, do not
find any and therefore issue a new compilation at level 3 that is then changed
to 2 again. In this case, we issue approximately 40 OSR compilations but never
use them until we finally OSR compile at level 4 (see log [4]).

Solution:
I changed 'SimpleThresholdPolicy::event' such that it does not use
'highest_osr_comp_level()' for the lookup but the current comp level. Like this,
we always perform OSR if there is an OSR nmethod available for the current BCI
that has a higher compilation. I also checked the other usages of
'highest_osr_comp_level()' and they seem to be fine.

Testing
JPRT + DeoptimizeMultipleOSRTest

Thanks,
Tobias


[1] 'SimpleThresholdPolicy::event' invokes
'AdvancedThresholdPolicy::method_back_branch_event'
[2] simpleThresholdPolicy.cpp lines 215f
[3] Logs (note missing 'OSR entry @ pc' in failed.log showing that no OSR is
performed)
https://bugs.openjdk.java.net/secure/attachment/23183/failed.log
https://bugs.openjdk.java.net/secure/attachment/23185/fixed.log
[4] Logs with -Xcomp
https://bugs.openjdk.java.net/secure/attachment/23184/failed_Xcomp.log
https://bugs.openjdk.java.net/secure/attachment/23186/fixed_Xcomp.log