On Thu, 8 Apr 2021 16:08:06 GMT, Richard Reingruber <rr...@openjdk.org> wrote:
>> Robbin Ehn has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains six commits: >> >> - White space fixes >> - Merge branch 'master' into SuspendInHandshake >> - Review fixes >> - Merge branch 'master' into SuspendInHandshake >> - Merge branch 'master' into SuspendInHandshake >> - 8257831: Suspend with handshake (review baseline) > > src/hotspot/share/runtime/handshake.cpp line 630: > >> 628: // exiting. >> 629: } >> 630: } > > I need a little help learning the steps of this dance :) > > We reach here in _thread_in_vm. We cannot be suspended in this state. There > might be another thread waiting to handshake us to suspend us but why can't we > just ignore that and do the `_handshakee->set_exiting();` even without locking > HandshakeState::_lock? > > Adding a handshake operation is lock free, so even if the check > `SafepointMechanism::should_process(_handshakee)` in L619 returns false a new > operation to process could have been added concurrently such that > `SafepointMechanism::should_process(_handshakee)` would return true when we > execute `_handshakee->set_exiting();` in L620. What am I missing? `HandshakeState::suspend()` is a synchronous handshake and adding the handshake to the queue is lock free, but the execution of the synchronous handshake itself requires a `HandshakeState::claim_handshake()` call which does acquire the lock in question. We (the suspend requester) hold the lock while the handshake is being processed so we either detect that _handshakee->set_exiting() won the race (in the target thread) or we (the suspend requester) win the race of setting the suspend flag so the target thread can't exit yet. Hopefully that helps explain this dance. ------------- PR: https://git.openjdk.java.net/jdk/pull/3191
