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

[David Holmes]

Severin,

Can you create a changeset with myself (dholmes) and Coleen (coleenp) as 
Reviewers, and with the file copyrights suitably updated. I'm not sure 
what form that will take given the dual copyright attributions but 
presumably the Red Hat line will need 2015 added.

If you email me the changeset directly I will apply it to the 
jdk9/hs-rt/hotspot/ forest.

Thanks,
David

On 7/01/2015 2:59 PM, David Holmes wrote:
> 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
>>>>>
>>