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

[Andrew Haley]

On 1/28/19 9:38 AM, Roman Kennke wrote:
> 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?

OK. It's a bit odd to see explicit use of load/store exclusive in the
Shenandoah code, but that isn't something your patch changes.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671