RFR(xs): 8211387: [Zero] atomic_copy64: Use ldrexd for atomic reads on ARMv7

[Andrew Haley]

On 10/05/2018 02:40 PM, Severin Gehwolf wrote:
>> Also I thought that if ldrex was not paired with a strex then you should 
>> at least issue clrex - as done in generate_atomic_load_long() in 
>> stubGenerator_arm.cpp
>
> I'll defer to Andrew Haley for this.

I'm skeptical that CLREX is necessary. The classic CAS for Arm is

    MOV  R1, #0xFF             ; load the ?lock taken? value
try LDREX    R0, [LockAddr]    ; load the lock value
    CMP R0,  #0                ; is the lock free?
    STREXEQ  R1, R0, [LockAddr]; try and claim the lock
    CMPEQ R0, #0               ; did this succeed?
    BNE try                    ; no ? try again. . .
; yes ? we have the lock

There's no CLREX, and no-one ever reported any problem. CLREX could be
a performance boost because it takes the cache line out of exclusive
state back to shared state, reducing later bus traffic.

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