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

[Vladimir Kozlov]

This looks reasonable to me but Igor is more familiar with this.

Thanks,
Vladimir

On 10/29/14 7:54 AM, Tobias Hartmann wrote:
> 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
>