RFR: 8266557: assert(SafepointMechanism::local_poll_armed(_handshakee)) failed: Must be [v3]
Daniel D.Daugherty
dcubed at openjdk.java.net
Thu Jun 3 16:11:46 UTC 2021
On Thu, 3 Jun 2021 15:27:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:
>> "Change of just using the queue to check for pending handshakes": also means we must remove the handshake from the queue after it have been executed.
>> I consider the decrement as the marking of "it have been executed".
>>
>> Therefore anything after the decrement, should stay after and not float above the dec, to follow the protocol.
>> If disregard ordering side-effects when removing the last in queue with CAS, if the removal happens before the decrement means if the handshakee ask "should process" it could say no before we decrement.
>>
>> This release to the removal of the operation is match with the acquire on is_empty().
>> Normally the removal would had used the release from the mutex lock, but here we hold the lock over several operations.
>
> Ok, although since all it matters for is_empty() is that there is at least one element in the queue and to remove the last element we always use a CAS it should be okay. I now realize that we could have also removed the operation from the queue as before if it is not the last one, so that would save the second traversal of the queue. But I see that if we want to maintain the invariant "If the handshake operation is not completed it must be on at least one queue" then we need to do it like this.
Did you guys decide the comment needed updating or not?
I can't figure that out from the above.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3973
More information about the hotspot-runtime-dev
mailing list