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

[David Holmes]

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.
>