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

David Holmes david.holmes at oracle.com
Sun Oct 30 21:26:26 UTC 2016

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.


> Thanks,
> Andrew.

More information about the hotspot-gc-dev mailing list