RFR: 8320318: ObjectMonitor Responsible thread

[Fredrik Bredberg]

On Wed, 11 Sep 2024 13:42:06 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 217:
>> 
>>> 215:   stlr(zr, owner_addr);
>>> 216:   membar(StoreLoad);
>>> 217: 
>> 
>> Is there some reason we need a `memory_order_conservative` store here?
>> You may not really need a `StoreLoad` here, as long as `ObjectMonitor::owner` is always read with `ldar` or `casal`. `Atomic::cmpxchg()` uses sequentially-consistent ops by default.
>> Reason: on AArch64, `stlr;ldar` is sequentially consistent, which is stronger than release|acquire.
>
> Oh, not just sequentially consistent, but also barrier-ordered-before.

The reason is described [here](https://github.com/openjdk/jdk/blob/f9ddfc6fb0780a7d6e933a40ecd3cd458a058f04/src/hotspot/share/runtime/objectMonitor.cpp#L1106). If you look in [ObjectMonitor::exit](https://github.com/openjdk/jdk/blob/f9ddfc6fb0780a7d6e933a40ecd3cd458a058f04/src/hotspot/share/runtime/objectMonitor.cpp#L1132C6-L1132C25)() you'll see that this there is a call to [OrderAccess::storeload](https://github.com/openjdk/jdk/blob/f9ddfc6fb0780a7d6e933a40ecd3cd458a058f04/src/hotspot/share/runtime/objectMonitor.cpp#L1184)() just after [release_clear_owner](https://github.com/openjdk/jdk/blob/f9ddfc6fb0780a7d6e933a40ecd3cd458a058f04/src/hotspot/share/runtime/objectMonitor.cpp#L1183)(), so I'm just doing the same as has been done in the C++ slow-path for long. I used `membar(StoreLoad);` in all other platforms, and I wanted it to be consistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19454#discussion_r1756663884