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

[Roman Kennke]

Currently, we have a bit of a mess in
ShenandoahBarrierSetAssembler::cmpxchg_oop(): It has special code paths
for C1-only (everthing under the boolean arg 'encode') and it has a code
path for !ShenandoahCASBarrier. Also, while C1 actually does not
exchange, we call it with exchange==true and cmove the result. This is
backwards. Also, we hacked to call storeval-barrier in C1-only path,
because it can't easily be done otherwise in C1. Streamlining this code
would help tremendously to clarify the actual CAS barrier algorithm,
which is currently buried under all those special paths.

The proposed change does:
- Extract the C1-specific paths (currently misnomed under 'encode') into
shenandoahBarrierSetC1.cpp
- Removed !ShenandoahCASBarrier path from assembler, generate
non-Shenandoah-CASes in C2 instead
- Make C1 generate the boolean version

Bug:
https://bugs.openjdk.java.net/browse/JDK-8217016
Proposed fix/refactoring:
http://cr.openjdk.java.net/~rkennke/JDK-8217016/webrev.00/

Testing: hotspot_gc_shenandoah, bunch of specjvm tests

Ok?

Thanks,
Roman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190114/0f9b16de/signature.asc>