RFR(S): 8062169: Multiple OSR compilations issued for same bci
igor.veresov at oracle.com
Wed Oct 29 21:37:18 UTC 2014
Looks good to me.
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.
> 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