JDK-8062169 : Multiple OSR compilations issued for same bci
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-10-27
  • Updated: 2015-06-03
  • Resolved: 2014-10-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u40Fixed 9 b40Fixed
Related Reports
Relates :  
JDK-8061817 - Whitebox.deoptimizeMethod() does not deoptimize all OSR versions of method
Description
While fixing JDK-8061817 I noticed that under some circumstances the VM performs multiple OSR compilations for the same method/bci flooding the JIT compilers with requests. The compiled versions are not used and the VM continues interpreting the method and issuing new requests.

It only happens if we have several OSR versions of the same method for different bci's. 

Logs look like this:

request:  DeoptimizeMultipleOSRTest::triggerOSR osr_bci: 89 comment: tiered count: 79872 hot: yes
    353   55 %  b  2       DeoptimizeMultipleOSRTest::triggerOSR @ 89 (114 bytes)
Installing osr method (2) DeoptimizeMultipleOSRTest.triggerOSR(ZJ)V @ 89
request:  DeoptimizeMultipleOSRTest::triggerOSR osr_bci: 89 comment: tiered count: 80896 hot: yes
    355   56 %  b  2       DeoptimizeMultipleOSRTest::triggerOSR @ 89 (114 bytes)
Installing osr method (2) DeoptimizeMultipleOSRTest.triggerOSR(ZJ)V @ 89
request:  DeoptimizeMultipleOSRTest::triggerOSR osr_bci: 89 comment: tiered count: 81920 hot: yes
    359   57 %  b  2       DeoptimizeMultipleOSRTest::triggerOSR @ 89 (114 bytes)
Installing osr method (2) DeoptimizeMultipleOSRTest.triggerOSR(ZJ)V @ 89
request:  DeoptimizeMultipleOSRTest::triggerOSR osr_bci: 89 comment: tiered count: 82944 hot: yes
    362   58 %  b  2       DeoptimizeMultipleOSRTest::triggerOSR @ 89 (114 bytes)
Installing osr method (2) DeoptimizeMultipleOSRTest.triggerOSR(ZJ)V @ 89
request:  DeoptimizeMultipleOSRTest::triggerOSR osr_bci: 89 comment: tiered count: 83968 hot: yes
    365   59 %  b  2       DeoptimizeMultipleOSRTest::triggerOSR @ 89 (114 bytes)
Installing osr method (2) DeoptimizeMultipleOSRTest.triggerOSR(ZJ)V @ 89
request:  DeoptimizeMultipleOSRTest::triggerOSR osr_bci: 89 comment: tiered count: 84992 hot: yes
    367   60 %  b  2       DeoptimizeMultipleOSRTest::triggerOSR @ 89 (114 bytes)
Installing osr method (2) DeoptimizeMultipleOSRTest.triggerOSR(ZJ)V @ 89
request:  DeoptimizeMultipleOSRTest::triggerOSR osr_bci: 89 comment: tiered count: 86016 hot: yes
    370   61 %  b  2       DeoptimizeMultipleOSRTest::triggerOSR @ 89 (114 bytes)
Installing osr method (2) DeoptimizeMultipleOSRTest.triggerOSR(ZJ)V @ 89

[...]

request:  DeoptimizeMultipleOSRTest::triggerOSR osr_bci: 89 comment: tiered count: 118784 hot: yes
    457   93 %  b  4       DeoptimizeMultipleOSRTest::triggerOSR @ 89 (114 bytes)
Installing osr method (4) DeoptimizeMultipleOSRTest.triggerOSR(ZJ)V @ 89
    460   92 %     2       DeoptimizeMultipleOSRTest::triggerOSR @ 89 (114 bytes)   made not entrant
Comments
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 next backbranch event is triggered 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]). [1] 'SimpleThresholdPolicy::event' that 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
29-10-2014
The fix for JDK-8061817 adds the test 'DeoptimizeMultipleOSRTest' that triggers this bug.
29-10-2014