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

[David Holmes]

On 31/10/2016 4:36 AM, Andrew Haley wrote:
> On 29/10/16 11:37, Hiroshi H Horii wrote:
>>> The most recent change also penalizes current platforms that do not
>>>> implement the release-CAS with an additional acquire. That might be not
>>>> an issue for TSO platforms, but others will be affected.
>>>>
>>>> While we think other platforms could quickly adapt to this, this would
>>>> force that the developer that implements this for other platforms
>>>> (arm/aarch64) to be stuck with re-analyzing these issues. We
>>>> do not think this is fair. We think this is a change (or set of
>>>> changes) that needs to be pushed for all platforms at the same time.
>>
>> Sure. I would like to ask developers for the other platforms to consider
>> this change.
>
> OK, I will.  Can you please point me to the change and what it means?
>
> 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. 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.

Cheers,
David

> Thanks,
>
> Andrew.
>