RFR: JDK-8207169: X86: Modularize cmpxchg-oop assembler for C1 and C2

[Roman Kennke]

I am x-posting hotspot-compiler-dev and hotspot-gc-dev because it
touches both areas.

Currently, cmpxchg-oop is generated a single instructions plus probably
some oops-compression. Shenandoah GC (and most likely other concurrent
compacting GCs) needs to generate some more code to deal with possible
false-negatives when comparing old-value with the field contents.

The way we solve it in Shenandoah is to basically retry (with resolved
expected-value) on the failed-path of the CAS. Another solution (I
believe ZGC does that) is to punch the resolved value into the field
(using a CAS) before doing the actual CAS.


We want to do this in assembly because:
1. it is very cumbersome and error-prone to construct the LIR and ideal
graph for the retry-loop.
2. the assembly can be reused for both C1 and C2
3. the generated code is pretty much the same

This change includes both C1 and C2 changes, and it should probably be
broken up, but I wanted to present the whole picture first, so that we
can discuss the solution with all aspects.

Some notes:

- The BarrierSetAssembler::cmpxchg_oop*() paths are only used when
BSA::handle_cmpxchg_oop() returns true. This is done because the
(Shenandoah version) BSA::cmpxchg_oop() requires 2 tmp registers, and we
don't want to penalize GCs that don't need this by allocating 2
registers that are subsequently not used.
- I added a diagnostic flag BarrierSetAlwaysHandlesCmpxchg to be able to
exercise the BSA::cmpxchg_oop() path even for other GCs, e.g. for
testing purposes. We can remove that if it's too much hassle.
- I want to be able to distinguish the case where expected-value is
known to be NULL, because in this case we don't need the extra handling
of cmpxchg_oop() and can use plain CAS.
- I want to distinguish entries for c1 and c2 into BSA because we are
doing some extra fluff for C1 (namely, resolving the cmpval because we
cannot easily do this in LIR)
- the compressing of uncompressed oops is moved into the C1 version of
BSA::cmpxchg_oop()

Bug:
https://bugs.openjdk.java.net/browse/JDK-8207169
Webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8207169/webrev.00/

What do you think? Can I get reviews?

Thank you!
Roman