P2
Atomic::add is currently specified as "<fence> add-value-to-dest <membar StoreLoad|StoreStore>". However, this specification is not followed by all platforms. Especially on PPC64, this very conservative memory ordering is not desirable for performance critical usages.
At the moment, there is one place where it's known that the memory barriers on PPC64 and s390 are not sufficient which was recently introduced byJDK-8195099 (Concurrent safe-memory-reclamation mechanism).
Therefore, we should have configurable semantics similar to the ones introduced for Atomic::cmpxchg withJDK-8155949.
The same applies to the remaining read-modifiy-write atomics.
At the moment, there is one place where it's known that the memory barriers on PPC64 and s390 are not sufficient which was recently introduced by
Therefore, we should have configurable semantics similar to the ones introduced for Atomic::cmpxchg with
The same applies to the remaining read-modifiy-write atomics.
- relates to
-
JDK-8195099 Concurrent safe-memory-reclamation mechanism
-
- Resolved
-
-
JDK-8222034 Thread-SMR functions should be updated to remove work around
-
- Resolved
-