RFR: 8253464: ARM32 Zero: atomic_copy64 is incorrect, breaking volatile stores

[Andrew Haley]

On Tue, 22 Sep 2020 14:12:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There is a regression introduced by addition of ARMv7-specific block by JDK-8211387. It readily manifests as crash
> during jcstress initialization, and investigation points at broken volatile stores. Reverting JDK-8211387 from head JDK
> makes ARM32 start and run jcstress.  The underlying reason seems to be the half-done `atomic_copy64`: it does the load
> with exclusive load, but then defers to the C++ store. Somewhere during handing over the value from the asm load to C++
> store and/or C++ store itself, we garble the value. The way out is to implement the whole thing in asm.   Also see
> `StubGenerator::generate_atomic_load_long` and `StubGenerator::generate_atomic_store_long` in `stubGenerator_arm.cpp`,
> that do roughly the same thing and were the basis for this implementation.  Attention @theRealAph, @bulasevich.
> 
> Testing:
>  - [x] ARM32 Linux zero release jcstress run

OK. It's fugly, but as far as I know there really is no better way to do it. From what I remember (it's been a while)
even LDREXD wasn't guaranteed to be atomic unless accompanied by a corresponding STREXD at the same address. However,
later versions of the Arm ARM do state that LDREXD is single-copy atomic, so we're good.

-------------

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/299