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

[David Holmes]

On 7/06/2021 1:49 pm, Patricio Chilano Mateo wrote:
> 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, 

Those "definitions" are not definitions - the semantics of combining 
loadstore|storestore are sufficient to implement release but not 
necessary. If all you have is loadstore and storestore style barriers 
then that combination is what you need to implement release semantics. 
But release semantics (and acquire semantics) are weaker than that.

> 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().

We should always try to use the correct logical memory barrier for a 
given situation, without too much concern about whether or not a given 
platform can implement "finer-grained" barriers. But on the flip-side if 
proving the correctness of a weaker barrier is difficult to reason about 
(or easily broken by simple code changes) then stick with a coarser 
barrier. Performance issues may sometimes force you in a particular 
direction in any case.

Cheers,
David
-----

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