(S) RFR: 8157904: Atomic::cmpxchg for jbyte is missing a fence on initial failure
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.
More information about the hotspot-runtime-dev