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.
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 |
|---|---|
8u20Fixed  |
9 b04Fixed |
Related Reports
|
Blocks :
|
Description
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.
Comments
|