-
Bug
-
Resolution: Fixed
-
P3
-
17, 21, 22, 23, 24
-
b06
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8336133 | 23.0.1 | Erik Österlund | P3 | Resolved | Fixed | b03 |
JDK-8335687 | 23 | Erik Österlund | P3 | Resolved | Fixed | b31 |
Relates to - https://bugs.openjdk.org/browse/JDK-8331911
is_armed() check in barrierSetNMethod returns early if the nmethod is not armed.(https://github.com/openjdk/jdk/blob/71a692ab435fdeea4ce8f8db7a55dd735c7c5016/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L175-L177).
Hence, cross-modify fence is not executed always. (https://github.com/openjdk/jdk/blob/71a692ab435fdeea4ce8f8db7a55dd735c7c5016/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L189).
The nmethod entry barriers guard modification to instructions and data through a mixed bag of synchronous and asynchronous cross modifying code. By skipping the cross modification fence we perform an incomplete synchronous instruction cross modification. We should perform cross modification fence always.
- backported by
-
JDK-8335687 Missing unconditional cross modifying fence in nmethod entry barriers
-
- Resolved
-
-
JDK-8336133 Missing unconditional cross modifying fence in nmethod entry barriers
-
- Resolved
-
- relates to
-
JDK-8310239 Add missing cross modifying fence in nmethod entry barriers
-
- Closed
-
-
JDK-8331911 Reconsider locking for recently disarmed nmethods
-
- Resolved
-
-
JDK-8337778 Regression in SPECjvm2008-Derby-ZGC on linux-aarch64
-
- Closed
-
- links to
-
Commit openjdk/jdk/c0604fb8
-
Commit openjdk/jdk/d383365e
-
Review openjdk/jdk/19990
-
Review openjdk/jdk/20036
-
Review(master) openjdk/jdk21u-dev/1131