JDK-8202080 : Introduce ordering semantics for Atomic::add and other RMW atomics
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 11
- Priority: P2
- Status: Resolved
- Resolution: Fixed
- Submitted: 2018-04-20
- Updated: 2019-04-05
- Resolved: 2018-05-07
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 11 |
|---|
11 b13Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
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 by JDK-8195099 (Concurrent safe-memory-reclamation mechanism). Therefore, we should have configurable semantics similar to the ones introduced for Atomic::cmpxchg with JDK-8155949. The same applies to the remaining read-modifiy-write atomics.