-
Bug
-
Resolution: Fixed
-
P2
-
11, 12, 13
-
b30
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8217935 | 13 | Per Liden | P2 | Resolved | Fixed | b06 |
JDK-8218368 | 12.0.2 | Per Liden | P2 | Resolved | Fixed | b01 |
JDK-8218320 | 12.0.1 | Per Liden | P2 | Resolved | Fixed | b06 |
JDK-8237251 | 11.0.7 | Per Liden | P2 | Resolved | Fixed | b01 |
The C1 load barrier stub for ZGC can emit a patching area for a lea instruction. However, the call into the VM to do the patching at this site is not associated with a proper oop map. As a result, we can end up with a stale oop in the base pointer register if a GC safepoint happens when we enter the VM to patch.
This problem is not super easy to reproduce by default, but is a serious bug when it happens. However, it is fairly easy to reproduce when also injecting a small delay in the ZNMethodTable::register_nmethod().
The proposed solution is to never allow patching to happen inside the load barrier stub. Instead, if patching is needed, we emit the lea instruction as part of the load preceding the load barrier. That will automatically generate the proper oop map for the patch site.
This problem is not super easy to reproduce by default, but is a serious bug when it happens. However, it is fairly easy to reproduce when also injecting a small delay in the ZNMethodTable::register_nmethod().
The proposed solution is to never allow patching to happen inside the load barrier stub. Instead, if patching is needed, we emit the lea instruction as part of the load preceding the load barrier. That will automatically generate the proper oop map for the patch site.
- backported by
-
JDK-8217935 ZGC: Broken oop map in C1 load barrier stub
- Resolved
-
JDK-8218320 ZGC: Broken oop map in C1 load barrier stub
- Resolved
-
JDK-8218368 ZGC: Broken oop map in C1 load barrier stub
- Resolved
-
JDK-8237251 ZGC: Broken oop map in C1 load barrier stub
- Resolved