RFC Literally: 8232782: streamline post-LRB CAS barrier (aarch64)

[Aleksey Shipilev]

Hi,

On 5/15/20 5:05 PM, Nilsen, Kelvin wrote:
> Have run into a few challenges in that the AARCH64 variant of cmpxchg_oop has different arguments
> than the x86 version.  In particular, AARCH64 has acquire, release, weak, and is_cae boolean
> arguments in place of the single Boolean exchange argument.  I've been sleuthing though the
> implementation, but some "comments" would be very helpful if someone else is already familiar
> with this code as I am relatively new to both HotSpot and Shenandoah code bases, and to AARCH64
> as well.
> Are these arguments providing support for ...
>    different variants of ARM?
>    different contextual state?  
>    experimentation with different code generation models?
>    something else?

The usual CAS we all love and cherish is usually a sequentially-consistent strong compare-and-set.

Other variants are different relaxations/flavors of CAS:
  *) acquire/release: relaxes the memory ordering on CAS from seqcst to acq/rel; it is sometimes
useful when seqcst is not really needed, or there is a seqcst operation nearby already. But, it is
rather special optimization, and it should not be used by default;
  *) weak: relaxes the "strong" property, i.e. CAS can sporadically fail even when "compare value"
is what we want. It is rather useful for LL/SC-based CAS loops, where we would retry the loop on
whatever failure anyway, so we might as well use the weak form;
  *) is_cae: turns CAS into CAE (compare-and-exchange); in Hotspot nomenclature, it means you get to
see the "failure witness", that is the actual memory value compare was done against. This can be
exploited in Shenandoah CAS barrier [IIRC, x86 version already does].

When in doubt, use the default CAS.

> My working assumptions are:
> 
> 1. Multiple concurrent reader threads may discover the same previously uncopied object and decide
> to copy it.  Each one in parallel copies the object and then uses CAS to "mark with forwarding
> address".  The race is resolved to the thread that succeeds with CAS.  The other threads abandon
> their copies and use the address "supplied" by the winning copy.

Yes. That is how it works. It should also be noted this happens before object reference is exposed
to the rest of runtime system (including mutators), and only to-space references would ever be
exposed. This is so called "strong to-space invariant".

Previous incarnation of Shenandoah employed a weak to-space invariant, where you could see the
from-space reference, and that forced CAS barrier paths to assume any conflicting store might as
well be the store of from-space reference. Hence the retry loop...

> 2. All threads will heal in place the obsolete pointer to the original object.  But the healing
> process for each address also needs a lock, because a parallel mutator thread may overwrite the
> reference field between the moment when the reader fetched its value and attempts to replace the
> value with the relevant forwarding pointer.  What does this lock look like to the healing reader?
> To the mutator?  Or is there some argument as to why no locking is necessary here?

If GC needs to update the reference to from-space object with reference to its to-space copy, GC
just does the CAS(expect-from-space, put-to-space), and that is enough to resolve conflicts with
either other GC threads trying the concurrent update, or mutators storing the value, even under the
race. That is, in core, what "concurrent update references" phase does over the entire heap.

Since CAS is atomic, it should not be possible to lose the mutator write. The update CAS might fail,
and if that CAS was strong, that _definitely_ means something had overwritten the old, to-space
reference. That means it was either the GC/mutator forwarding CAS-ed update, or mutator write.
Mutator writes with strong to-space invariant mean we don't have to retry the update. This is what
enables the simplification for CAS barrier you are working on :)

Hope this helps.

-- 
Thanks,
-Aleksey