-
Bug
-
Resolution: Fixed
-
P4
-
8, 10, 11, 12, 13
-
b06
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8227521 | 11.0.6-oracle | Erik Österlund | P4 | Resolved | Fixed | b01 |
JDK-8227144 | 11.0.5 | Erik Österlund | P4 | Resolved | Fixed | b01 |
JDK-8258771 | openjdk8u292 | Peter Zhelezniakov | P4 | Resolved | Fixed | b01 |
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.
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.
- backported by
-
JDK-8227144 ciMethodData::load_data() unpacks MDOs with non-atomic copy
- Resolved
-
JDK-8227521 ciMethodData::load_data() unpacks MDOs with non-atomic copy
- Resolved
-
JDK-8258771 ciMethodData::load_data() unpacks MDOs with non-atomic copy
- Resolved