RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64
aph at redhat.com
Mon Oct 31 09:32:44 UTC 2016
On 30/10/16 21:26, David Holmes wrote:
> On 31/10/2016 4:36 AM, Andrew Haley wrote:
>> And, while we're on the subject, is memory_order_conservative actually
>> defined anywhere?
> No. It was chosen to represent the current status quo that the Atomic::
> ops should all be (by default) full bi-directional fences.
Does that mean that a CAS is actually stronger than a load acquire
followed by a store release? And that a CAS is a release fence even
when it fails and no store happens?
And that a conservative load is a *store* barrier?
> It is a place holder until this memory order stuff is fleshed out in
> hotspot. We didn't adopt C++ memory_order_seq_cst as is isn't
> obvious that actually matches our current semantics. At least it
> isn't obvious to me.
It's not obvious to me either, because I don't know what our current
semantics are. But I believe that if we need anything stronger than
sequential consistency we should look at fixing the callers of the
Atomic:: ops. But I guess the real problem is that we don't know
which callers actually need the super-strong guarantees, or even that
More information about the hotspot-gc-dev