JDK-8216987 : ciMethodData::load_data() unpacks MDOs with non-atomic copy
- Type: Bug
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 8,10,11,12,13
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2019-01-14
- Updated: 2020-12-21
- Resolved: 2019-01-29
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 11 | JDK 13 | Other |
|---|---|---|
| 11.0.5Fixed | 13 b06Fixed  |
openjdk8u292Fixed |
Description
The ciMethodData::load_data() member function copies a raw MDO to the compiler mirror of said MDO. However, the copy is performed using a non-atomic copy function, despite being updated concurrently. This could potentially cause word tearing when reading metadata pointers, causing the VM to crash... in theory. While this is not a problem when unpacking the extra data section, because it is done under a lock, the same can not be said about the rest of the MDO. So it should either be protected by a lock, or use an atomic copy function instead.
Comments
|