RFR: 8257831: Suspend with handshakes [v4]

[Daniel D.Daugherty]

On Thu, 8 Apr 2021 16:08:06 GMT, Richard Reingruber <rrich at 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