RFR(M): 8155949: Support relaxed semantics in cmpxchg

[David Holmes]

Filed: https://bugs.openjdk.java.net/browse/JDK-8157904

Atomic::cmpxchg_general for jbyte is missing a fence on initial failure

David

On 26/05/2016 11:09 AM, David Holmes wrote:
> Hi Kim,
>
> On 26/05/2016 10:04 AM, Kim Barrett wrote:
>>> On May 24, 2016, at 5:37 AM, Doerr, Martin <martin.doerr at sap.com> wrote:
>>>
>>> Hi David and Andrew,
>>>
>>> sorry for missing this one. There were too many emails.
>>>
>>> After moving the jint version as well, there was not much left of
>>> atomic.cpp.
>>> I think it doesn't make any sense to keep a couple of trivial
>>> functions in the cpp file.
>>> Therefore, I have removed atomic.cpp and moved the remaining small
>>> functions into the inline file.
>>>
>>> Webrev is here:
>>> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.05/
>>
>> ------------------------------------------------------------------------------
>>
>>  100 inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte
>> *dest, jbyte comparand, cmpxchg_memory_order order)
>>
>> The addition of the order option makes it a bit more obvious that this
>> does not, and never has, executed any fences in the immediate failure
>> case, e.g. when
>>
>>  111   while (cur_as_bytes[offset] == comparand) {
>>
>> is false on the first iteration.  This seems like a bug.  Assuming it
>> is, I'm not sure whether this should be dealt with as part of this
>> changeset, or moved to a separate bug for this (pre-existing) issue.
>> I think only ARM targets (and zero?) are lacking specialized cmpxchg
>> on bytes and so use this version?
>
> I'll file a separate bug for that.
>
> Thanks,
> David
> ------
>
>
>> Sorry I didn't notice this previously.
>>
>> ------------------------------------------------------------------------------
>>
>>
>> Other than that and the already mentioned (pre-existing) Atomic::add
>> for jlong return value problem, this looks good.
>>