-
Bug
-
Resolution: Fixed
-
P4
-
9
-
b48
-
generic
-
generic
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8083193 | emb-9 | Severin Gehwolf | P4 | Resolved | Fixed | team |
| JDK-8086420 | 8u65 | Severin Gehwolf | P4 | Resolved | Fixed | b01 |
| JDK-8073841 | 8u60 | Severin Gehwolf | P4 | Resolved | Fixed | b05 |
| JDK-8137583 | emb-8u65 | Unassigned | P4 | Resolved | Fixed | b01 |
| JDK-8077437 | emb-8u60 | Severin Gehwolf | P4 | Resolved | Fixed | team |
Some code in hotspot depends on Atomic::xchg to be a full memory barrier. Example:
void Parker::park(bool isAbsolute, jlong time) {
// Ideally we'd do something useful while spinning, such
// as calling unpackTime().
// Optional fast-path check:
// Return immediately if a permit is available.
// We depend on Atomic::xchg() having full barrier semantics
// since we are doing a lock-free update to _counter.
if (Atomic::xchg(0, &_counter) > 0) return;
However, the Zero implementation is not implemented as a full memory barrier.
void Parker::park(bool isAbsolute, jlong time) {
// Ideally we'd do something useful while spinning, such
// as calling unpackTime().
// Optional fast-path check:
// Return immediately if a permit is available.
// We depend on Atomic::xchg() having full barrier semantics
// since we are doing a lock-free update to _counter.
if (Atomic::xchg(0, &_counter) > 0) return;
However, the Zero implementation is not implemented as a full memory barrier.
- backported by
-
JDK-8073841 Zero: Atomic::xchg and Atomic::xchg_ptr need full memory barrier
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-