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

[Tobias Hartmann]

Vladimir, Igor,

thanks for the reviews.

Best,
Tobias

On 29.10.2014 22:37, Igor Veresov wrote:
> 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
>>>
>