RFR: 8232782: Shenandoah: streamline post-LRB CAS barrier (aarch64)

[Roman Kennke]

On Wed, 2020-06-24 at 16:22 +0100, Andrew Haley wrote:
> On 24/06/2020 15:48, Roman Kennke wrote:
> > On Wed, 2020-06-24 at 15:29 +0100, Andrew Haley wrote:
> > > On 24/06/2020 14:54, Nilsen, Kelvin wrote:
> > > > Is this ok to merge?
> > > 
> > > One thing:
> > > 
> > > Some CPUs, in particular those based on Neoverse N1, can perform
> > > very
> > > badly when using ldxr/stxr. For that reason, all code doing CAS
> > > 
> > > I can't see any reason why your code needs to use ldxr/stxr. Is
> > > there
> > > any?
> > 
> > As far as I know, Shenandoah's AArch64-CAS-implementation always
> > did it
> > that way (don't remember why). If regular CAS is generally better,
> > then
> > we should go for it.
> 
> Does this algorithm need a full barrier even when CAS fails?

We need to do extra work *only* when CAS fails. We need to catch false
negatives -- when the compare-value is to-space (that's guaranteed) and
the value in memory is from-space copy of the same object.

Roman