JDK-8034188 : OSR methods may not be recompiled at proper compilation level after deoptimization
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-02-11
  • Updated: 2014-07-29
  • Resolved: 2014-02-26
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.
8u20Fixed 9 b04Fixed
Related Reports
Blocks :  
This bug may prevent methods that have been deoptimized from being recompiled at the proper level.

In remove_osr_nmethod we are trying to find the highest comp level by iterating though all linked osr-nmethods. But the code fails to take into account that the chained OSR-nmethods may belong to any nmethod in that class, not just that nmethod (as is the case for non-OSR nmethods.)

This bug has been present since the integration of tiered compilation.

Impact: May cause loss of performance
Likelihood: Unknown, but probably not uncommon in scenarios with lots of deopts. 
Workaround: Turn of tiered-compilation, but that will probably hurt performance even more.
Check that the osr-nmethod belongs to the current method.