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

[Andrew Haley]

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?

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