RFR(S): 8062169: Multiple OSR compilations issued for same bci
vladimir.kozlov at oracle.com
Wed Oct 29 16:08:44 UTC 2014
This looks reasonable to me but Igor is more familiar with this.
On 10/29/14 7:54 AM, Tobias Hartmann wrote:
> please review the following fix.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8062169
> Webrev: http://cr.openjdk.java.net/~thartmann/8062169/webrev.00/
> An existing OSR nmethod blocks OSR for the same method at other BCIs.
> 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 . 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 . 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 ).
> 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 ).
> 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.
> JPRT + DeoptimizeMultipleOSRTest
>  'SimpleThresholdPolicy::event' invokes
>  simpleThresholdPolicy.cpp lines 215f
>  Logs (note missing 'OSR entry @ pc' in failed.log showing that no OSR is
>  Logs with -Xcomp
More information about the hotspot-compiler-dev