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

[Igor Veresov]

Looks good to me.

igor

On Oct 29, 2014, at 6:08 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

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