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

[David Holmes]

On 31/10/2016 7:32 PM, Andrew Haley wrote:
> 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?

Yes. Yes.

   // All of the atomic operations that imply a read-modify-write action
   // guarantee a two-way memory barrier across that operation. Historically
   // these semantics reflect the strength of atomic operations that are
   // provided on SPARC/X86. We assume that strength is necessary unless
   // we can prove that a weaker form is sufficiently safe.

But there is some contention as to whether the actual implementations 
obey this completely.

>
> And that a conservative load is a *store* barrier?

Not sure what you mean. Atomic::load is not a r-m-w action so not 
expected to be a two-way memory 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.

Indeed. I don't know how to reliably analyse all uses to determine what 
"strength" is needed, or what features of that code enable, or reject, 
use of a particular strength. Ref the current discussions.

David

> Andrew.
>