RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64

[Andrew Haley]

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
any exist.

Andrew.