RFR(S) 8067331: Zero: Atomic::xchg and Atomic::xchg_ptr need full memory barrier

[David Holmes]

On 7/01/2015 2:54 PM, Coleen Phillimore wrote:
>
> This looks good.  Sorry for the delay reviewing it as it looks
> important.  Is there a small test case that can be written to test
> this?  (or no?)

No - I'll add noreg-hard. Testing for a missing memory-barrier is not 
practical.

Thanks,
David

> Coleen
>
> On 1/6/15, 8:47 PM, David Holmes wrote:
>> Can we get a second hotspot review please - this is quite straight
>> forward.
>>
>> Thanks,
>> David
>>
>> On 5/01/2015 12:21 PM, David Holmes wrote:
>>> Hi Severin,
>>>
>>> Sorry this slipped through the cracks before the holidays.
>>>
>>> On 16/12/2014 1:09 AM, Severin Gehwolf wrote:
>>>> Hi,
>>>>
>>>> Could someone please review and sponsor the following change?
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8067331
>>>> webrev:
>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8067331/webrev.02/
>>>>
>>>> The issue is that all atomic operations are expected to be full memory
>>>> barriers, but two implementations of the Zero variant JVM -
>>>> Atomic::xchg
>>>> and Atomic::xchg_ptr - use GCC's built-in __sync_lock_test_and_set
>>>> which
>>>> is an acquire barrier only. The fix adds full memory barriers manually
>>>> for those.
>>>>
>>>> Thoughts?
>>>
>>> Looks completely consistent with what I just saw in the aarch64 port
>>> code.
>>>
>>> I can sponsor this but we still need a second review.
>>>
>>> Thanks,
>>> David
>>>
>>>> Cheers,
>>>> Severin
>>>>
>