RFR: AArch64 remaining CAS-obj impls

[Roman Kennke]

Am Donnerstag, den 17.11.2016, 12:35 +0000 schrieb Andrew Haley:
> On 17/11/16 12:08, Roman Kennke wrote:
> > 
> > Am Donnerstag, den 17.11.2016, 11:48 +0000 schrieb Andrew Haley:
> > > 
> > > On 17/11/16 10:07, Roman Kennke wrote:
> > > > 
> > > > 
> > > > I found one more bug in my implementation. For
> > > > compareAndExchangeN, we need to restore the uncompressed old-
> > > > value
> > > > into the result register before leaving.
> > > > 
> > > > http://cr.openjdk.java.net/~rkennke/aarch64-cas/webrev.01/
> > > > 
> > > > Ok now?
> > > 
> > > What does this mean?
> > > 
> > > +        __ cmpxchg_oop_shenandoah(addr, cmpval, newval,
> > > Assembler::word, true, true, false);
> > > 
> > > No cheating by looking at the declaration of
> > > cmpxchg_oop_shenandoah!
> > 
> > ;-)
> > 
> > I know, it is not the crytal clear diamond of software engineering
> > :-)
> > 
> > In my defense, it's mostly adopted from existing code, and at least
> > it's consistent.
> > 
> > I agree it should be refactored, and if we go and do that, then for
> > all
> > of the similar cmpxchg() methods in MacroAssembler.
> 
> The maxims "tidy up as you go" and "don't make it any worse" apply
> here.  You've added another boolean; surely the least you can do is
> comment it at the call site.

I absolutely agree.

I am wondering about the acquire and release flags.

Release always seems to be 'true' thus making the store-exclusive
ordered, which I think must always be the case.

There seem to be acquiring versions of some CASes, which pass 'true'
for acquire, making the load-exclusive variants ordered too. However,
as far as I can tell, those instructions would never match because they
have a preceding non-acquiring instruction that has no predicate (or
weaker predicate). Is there a reason for the acquiring CASes, or can we
just drop them altogether?

This would get rid of those two flags, and leaves us with weak vs.
strong which I would replace by an enum.

Roman