RFR: 8223312: Utilize handshakes instead of is_thread_fully_suspended

[Robbin Ehn]

On Tue, 20 Oct 2020 07:12:01 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> 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

> Not clear to me this is so generic that it applies to Handshake::execute
> rather than being part of the operation. ??

We only have two other cases (other than JVM TI where we always do this).
This one, async exception:
    if (thread == receiver) {
      // Exception is getting thrown at self so no VM_Operation needed.
      THROW_OOP(java_throwable);
    } else {
      // Use a VM_Operation to throw the exception.
      Thread::send_async_exception(java_thread, java_throwable);
    }

And biased locking revoke where we don't do this, because it makes no sense revoking a lock if you have the bias :)
In that case we could assert we never try to revoke a self owned bias.

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

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