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

[Kim Barrett]

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

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.