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