RFR: 8267079: Support async handshakes that can be executed by a remote thread

[David Holmes]

Hi Man,

On 19/05/2021 4:55 am, Man Cao wrote:
> On Thu, 13 May 2021 02:05:30 GMT, Man Cao <manc at openjdk.org> wrote:
> 
>> Hi all,
>>
>> Can I have reviews for this small refactoring change? It resolves a pending concern from [JDK-8238761](https://bugs.openjdk.java.net/browse/JDK-8238761), clarifies the code and allows more use case of async handshakes. See [JDK-8267079](https://bugs.openjdk.java.net/browse/JDK-8267079) for detailed description.
>>
>> -Man
> 
> Thanks for the feedback!
> 
> For David's question, I'm looking for adding support for HandshakeState::try_process() to execute non-self executable async handshakes . The caller of try_process() could be the VM thread, or a third thread, or the original requesting thread.
> 
> Consider this scenario:
> 
> Thread A calls Handshake::enqueue(async_op, Thread_B);
> Thread X calls Handshake::execute(sync_op, Thread_B);
> 
> Thread X could be the same as thread A, or a third thread C. In either case, X can execute any non-self executable handshake op on B's queue if it is safe to do so. Currently only synchronous handshake can be executed.

Thanks for clarifying the usage scenario. I have a better understanding 
now of what you want to allow. Being able to process an async op on 
behalf of Thread B so that you can then process your own sync op, makes 
sense. Though if there is a self-only async op in the queue ahead of 
that, then you won't be able to proceed anyway.

> The goal is to support asynchronous handshake with all threads for JDK-8236485, and skipping threads that are blocked, without entering a safepoint in the requesting thread. The requesting thread can stop waiting if it has timed out. I experimented that it could work with some modification to the handshake code.

Not really getting this part. Why do you want to skip blocked threads? I 
read the brief discussion you mention below and it seems Erik asked the 
same question and I don't understand your answer - if a thread is 
blocked then it is handshake-safe and so the handshake should be fast. 
Or are you concerned that your handshake won't be able to proceed 
because of what else may be in a target thread's op queue, and you want 
to skip that target in that case?

Thanks,
David
-----


> A minimal requirement is to be able to safely check if the target thread is blocked, and skip them. This was disussed in https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2021-April/034697.html.
> The first four if conditions in HandshakeState::try_process() already check for this condition, provided that there is at least one non-self executable handshake op on the queue so that HandshakeState::claim_handshake() can return true. I'd like to extract the four if conditions in a single public method in JDK-8236485.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4005
>