RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be [v3]

[Patricio Chilano Mateo]

On Fri, 4 Jun 2021 22:46:08 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> As long as we have a release() fence after the handshake closure the reordering of decrementing _pending_threads and removing the operation from the queue shouldn't matter since the target doesn't read _pending_threads.
>
> "release operation: no reads or writes in the current thread can be reordered after this store."
> 
> But stores happened after this store may be reordered before. Which means the removal might happen even before the handshake operation was executed.
> 
> So we need to stop the store ("the relaxed CAS") from floating above the dec.
> 
> Dec with rel+acq gives: "No memory reads or writes in the current thread can be reordered before or after this store."

By release() fence I was referring to the definition in orderAccess (LoadStore | StoreStore), sorry for the confusion, which would be enough to prevent any of those writes to float above the barrier. I now see that dec( ,memory_order_release) might not necessarily provide that though so we would need to use OrderAccess::release() + dec( ,memory_order_relaxed) instead. But I see that using a full fence is probably easier to read. Also by looking at the implementations of dec() for arm32/aarch64 it seems the order parameter is ignored (always full fence) (?), which would defeat the purpose of using release().

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

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