RFR: JDK-8217016: Shenandoah: Streamline generation of CAS barriers

[Roman Kennke]

>> Right. This update implements the same thing in aarch64:
>>
>> http://cr.openjdk.java.net/~rkennke/JDK-8217016/webrev.01/
>>
>> It causes no regressions in hotspot_gc_shenandoah (we have a few
>> failures, but none of them are related to the patch and are pre-existing).
>>
>> Good?
> 
> I can't make any sense of the code. It looks like we're disabling the generation
> of CAS instructions in ShenandoahBarrierSetAssembler::cmpxchg_oop.

Why? Because of removal of this block:

-  if (!ShenandoahCASBarrier) {
...
-  }

?

This block has only been there because we haven't been strict on
generating the Shenandoah-CAS only with +ShenandoahCASBarrier. This has
been fixed, and we should never actually get there when
-ShenandoahCASBarrier.

The rest of the patch is refactoring the code such that all C1-specific
code is only done in shenandoahBarrierSetC1_aarch64.cpp. The C1-specific
paths have previously been under 'if (encode) {.. }' paths, which was
completely un-obvious unless you knew it.

Another change is that cset that follows the compare-and-swap-path is
now consistently generated at the end of cmpxchg_oop(). Before that, C1
would first generate a compare-and-exchange (?!) and then put a cmove()
in LIR behind it, which assumes correct flags out of cmpxchg_oop()
assembly, which is kindof odd.

Does that make more sense?

Roman