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

[David Holmes]

On 15/05/2021 5:31 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
> 
> Hi David,
> 
> By "remote" I mean any thread that is not the current running thread itself. Basically "remote" = "non-self". In the handhshake model's terminology, remote executable means "executing thread" != "target thread". Remote is commonly used as a synonym for "non-local" in literature about CPU and NUMA, e.g. "remote cache", "remote memory".
> 
> Do you prefer the old term "non_self_executable" over "remote_executable"?

Yes, because we are dealing with self or non-self. I don't think 
referring to self/current as "local" is appropriate terminology here, 
and so remote also does not fit IMO.

But I'm also confused about the general model here. To me async means 
the requestor does not wait for the operation to complete, so the 
requestor can never execute the operation here. That leaves only the 
target (which is what we currently have) or a third thread, which at the 
moment (ignoring sync/async aspect) only the VMThread is allowed because 
the operation happens at a safepoint. Are you looking to generalize this 
to allow an arbitrary third thread to execute the operation? If so I 
don't understand the model as it seems to me that what you are 
effectively asking for is a way to "suspend" a target thread until some 
arbitrary action is performed by another thread, but that thread can't 
initiate a handshake directly, so that responsibility falls to yet 
another thread.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4005
>