On Tue, 20 Oct 2020 07:12:01 GMT, Robbin Ehn <[email protected]> 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
