JDK-8224674 : NMethod state machine is not monotonic
- Type: Bug
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 13
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- Submitted: 2019-05-23
- Updated: 2019-08-15
- Resolved: 2019-07-18
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 13 | JDK 14 |
|---|---|
13 b31Fixed  |
14Fixed |
Related Reports
|
Duplicate :
|
|
|
Duplicate :
|
|
|
Relates :
|
Description
When two concurrent threads request different nmethod state transitions with different levels of dead, it sometimes happens that monotonicity of the state transitions is lost, and as a result, nmethods may resurrect in unfortunate races, and cause the VM to crash. Today, it is up to the caller to know if there could be any racing transitions, but it is very easy to slip. I can see a few examples of such slippage. However, the state transitions really should be monotonic; an nmethod is always be at least as dead as the most dead state requested.
Comments
|