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

[Robbin Ehn]

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, a couple of questions.

- The AsyncHandshakeClosure must still be on heap but when executed by a remote thread it looks like it's never deleted?
- In a normal work load there are very few handshakes, meaning there are almost never a "remote" thread.
  So if the requester uses the new AsyncHandshakeClosure, they will be almost always self/local executed.
  And there is no guarantee there will be any more handshakes, so the AsyncHandshakeClosure cannot be guaranteed to 
  finished. Since if the thread is in blocked state and there are not more handshakes it will not be executed.
  Which is the reason I did not separate them from the begging, to me it looks like very little adavantage to use 
  AsyncHandshakeClosure vs SelfExecutedHandshakeClosure.
  If you need guarantee that the handshake is executed, you cannot use AsyncHandshakeClosure and since there is almost never a remote thread and the performance difference should be very slim?

To me it sounds like you want to customize the yield method or manually loop the processing of 'normal' handshakes?

E.g. either customized yield as template or closure:
Handshake::execute(handshake, ON_YIELD); // synchronous call
Or
Handshake::enqueue(handshake);
while (!Handshake::process_handshakes(handshake)) { // Do one iteration
   // Do other stuff
}

So the processing is asynchronous but we use normal handshakes? 
(in both my examples the handshake may be on requesting threads stack, so there is no need for 'asynchronous' handshakes.)

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

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