RFR(M): 8155949: Support relaxed semantics in cmpxchg

Kim Barrett kim.barrett at oracle.com
Thu May 19 20:17:53 UTC 2016


> On May 18, 2016, at 7:52 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 18/05/2016 9:08 PM, Doerr, Martin wrote:
>> Hi David,
>> 
>> in comparison to C++11 or JEP 193, the hotspot C++ semantics are kind of unprecise for PPC64. That's the reason why we use 2 sync instructions which is the maximum conservative implementation.
>> 
>> C++11 and JEP 193 specify which barriers are needed in case cmpxchg fails.
> 
> The hotspot semantics are quite simple - no difference between success or failure - just two-way barriers around the operations.

The current ppc ports have have no post-barrier in the failure case.  That does seem
at variance from the documented hotspot semantics.

I’m not sure about aarch64, since it uses a compiler intrinsic (__sync_val_compare_and_swap) whose expansion I don’t know where to find.

sparc and x86 look fine, not surprisingly.




More information about the hotspot-runtime-dev mailing list