(S) RFR: 8157904: Atomic::cmpxchg for jbyte is missing a fence on initial failure

Andrew Haley aph at redhat.com
Wed Aug 24 17:05:13 UTC 2016


On 24/08/16 09:01, David Holmes wrote:
> On 24/08/2016 5:36 PM, Andrew Haley wrote:
>> On 22/08/16 08:54, David Holmes wrote:
>>> An earlier code review noticed that the default shared implementation of
>>> Atomic::cmpxchg(jbyte*) was missing the required post-memory-barrier in
>>> case of an initial failure:
>>
>> Just to satisfy my curiosity, why is the post-memory-barrier in
>> case of an initial failure required?  Is there some specification
>> somewhere that I can refer to?
> 
> In atomic.hpp:
> 
>    // All of the atomic operations that imply a read-modify-write action
>    // guarantee a two-way memory barrier across that operation.
> 
> and then each op has additional descriptions e.g.:
> 
>    // Performs atomic compare of *dest and compare_value, and exchanges
>    // *dest with exchange_value if the comparison succeeded. Returns prior
>    // value of *dest. cmpxchg*() provide:
>    // <fence> compare-and-exchange <membar StoreLoad|StoreStore>

OK; I guess it doesn't much matter from a performance point of view.
It's stronger than anything we get from Java and or C++11 intrinsics,
which struck me as odd.

Andrew.




More information about the hotspot-runtime-dev mailing list