RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended

[Robbin Ehn]

On Tue, 20 Oct 2020 02:28:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The main point of this change-set is to make it easier to implement S/R on top of handshakes.
>> Which is a prerequisite for removing _suspend_flag (which duplicates the handshake functionality).
>> But we also remove some complicated S/R methods.
>> 
>> We basically just put in everything in the handshake closure, so the diff just looks much worse than what it is.
>> 
>> TraceSuspendDebugBits have an ifdef, but in both cases it now just returns.
>> But I was unsure if I should remove now or when is_ext_suspend_completed() is removed.
>> 
>> Passes multiple t1-5 runs, locally it passes many jck:vm/nsk_jvmti/nsk_jdi/jdk-jdi runs.
>
> Hi Robbin,
> 
> IIUC the "waiting" part of `wait_for_ext_suspend_completion` is now implicitly handled in the handshake - correct?
> 
> Overall this seems like a great simplification.
> 
> A few minor comments below.
> 
> Thanks,
> David

Hi David, thanks for having a look.

> Hi Robbin,
> 
> IIUC the "waiting" part of `wait_for_ext_suspend_completion` is now implicitly handled in the handshake - correct?

A suspended Java thread may never transition back to java, never execute any more bytecodes.
The old 'fully' suspended gives more guarantees which we need to do some operations.
When we are in a handshake, the handshake gives us those guarantees, so it is enough that thread is considered
suspended.

So the answer is we wait until we are allowed to execute those operations (thread handshake safe), which is not
identical with fully suspended. But fully suspended is an implementation detail, the agent only knows about suspended.

> 
> Overall this seems like a great simplification.
> 
> A few minor comments below.
> 
> Thanks,
> David

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

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