RFR: 8253611: AArch64: Concurrency problems in JavaFrameAnchor

[Erik Österlund]

On Fri, 25 Sep 2020 07:00:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> It looks that `_last_Java_sp` is additionally used as acquire/release flag that guards the rest of the state. Yet, the
> coding in `javaFrameAnchor_aarch64.hpp` is incorrect at least in one place:
>     _last_Java_fp = src->_last_Java_fp;
>     _last_Java_pc = src->_last_Java_pc;
>     // Must be last so profiler will always see valid frame if has_last_frame() is true
>     _last_Java_sp = src->_last_Java_sp;
> 
> There should be `OrderAccess::release()` where the comment suggesting the ordering constraint actually is -- I believe
> that is a copy-paste error from x86. Other platforms have `release` thre. Additionally, it has to be matched with
> `OrderAccess::acquire()` before `_last_Java_sp` reads, which requires the shared code to use the platform-specific
> getter.  Testing:
>   - [x] Linux x86_64 tier1
>   - [x] Linux AArch64 tier1
>   - [x] Linux AArch64 tier2

Note that the x86 code is probably wrong too. The volatile store/load pair only guarantees release/acquire semantics
with the MSVC compiler (explicitly so). With for example GCC, it is explicitly stated that the compiler can and will
reorder volatile and non-volatile accesses. So the release/acquire will only work if all preceding/subsequent accesses
that were to be guarded by the release/acquire pair, are also volatile. And I doubt that is the case. So that seems
flawed nevertheless. So x86 should probably also be explicit about using release/acquire (for the compiler barriers).

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

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