RFR: 8257831: Suspend with handshakes [v2]

[Richard Reingruber]

On Tue, 6 Apr 2021 12:54:40 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> The only reason _suspended is volatile is to be able to make the the fast check in resume().
>> So disregard that early check and that it is volatile, the users of the flag uses HandshakeState lock for synchronizing reads and stores to that flag.
>> 
>> E.g
>> set_suspend(true);
>> set_async_suspend_handshake(true);
>> log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " suspended, arming ThreadSuspension", p2i(_handshakee));
>> ThreadSuspensionHandshake* ts = new ThreadSuspensionHandshake();
>> Handshake::execute(ts, _handshakee);
>> 
>> Before we have enqueued the async handshake there is no trap and but the flag set_suspend(true).
>> This means we will miss the async handshake and continue to executed with suspended flag.
>> 
>> Both flags and async handshake are set atomically by serializing over the HnadshakeState lock.
>> 
>> In this case we want to both know if we are suspended if so process the suspension.
>
> (technically this will be ordered by the poll is since polls are only disarmed by threads them selfs)
> (meaning if you really promise to call should_process() after you have seen "set_suspend(true);" you will see the async handshake since then we do take the HandshakeState lock.)

> Also when the suspend request happened while A was blocked then after
> current->set_thread_state_fence(_thread_blocked_trans); the check of
> is_suspended() will return true even if the handshake state lock is not
> acquired for the check

That statement of mine is wrong. (Hopefully) correct is that after the complete
state change from _thread_blocked to _thread_in_vm which includes being blocked
for a safepoint/handshake the current thread would be able to check
is_suspended() without holding the handshake state lock. It does not make a lot
of sense then because in an unsafe state JavaThread::current()->is_suspended()
will always return false.

> Thread A wait on OM X in blocked.
> Thread Z suspends Thread A, thread Z have no relation to OM X.
> Thread B unlocks OM X, thread B have no relation to the suspend request.
> Thread A locks OM X while blocked.
> Thread A was not allowed to lock OM X due to it is actually suspended.
> Thread A unlocks OM X and waits until resumed.

I understand that example now too: OM and suspend operations are unrelated. So I
thought it would be ok for A to enter OM X, but it is not. A thread must not
leave a safe state if it was suspended in that state (with a handshake). If it
did, e.g., its stack could become not walkable. And it must not enter the
monitor either.

Sorry for the confusion. The check is good.

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

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