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

[Robbin Ehn]

On Tue, 18 May 2021 19:23:40 GMT, Man Cao <manc at openjdk.org> wrote:

> I addressed the comments in the second commit.
> 
> For Robbin's question:
> 
> > The AsyncHandshakeClosure must still be on heap but when executed by a remote thread it looks like it's never deleted?
> 
> Great catch! Added delete in HandshakeState::try_process() similarly to HandshakeState::process_self_inner().
> 
> > 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?
> 
> I hope the reply to David could also answer this. I don't need a guarantee that the handshake is executed. I mainly need a safe approach to skip target threads that are blocked. Reusing the four if checks in HandshakeState::try_process() is a possible approach, and it would need async non-self executable handshake for HandshakeState::claim_handshake() to return true.
> 
> > To me it sounds like you want to customize the yield method or manually loop the processing of 'normal' handshakes?
> 
> Yes, that could work as well. I did find the "async" name confusing. If we support `Handshake::enqueue(handshake)` for 'normal' handshakes, it is basically an async submission of the 'normal' handshake. It also has the problem of how to deallocate the `HandshakeOperation` object, which is currently handled by `AsyncHandshakeOperation`.

Ok, I think I got what you are trying todo.
But if you don't need it to be execute and you are fine with it being never execute, you also must not enqueue more.
Since it's never executed it will never be freed, thus we are leaking memory every time one is enqueued.
Which means the issuer of the handshakes must keep track of what threads that have not completed it's previous async handshake and avoid enqueue more.

Since we don't want to do this, I'm guessing, you could processes them with VM thread during the the safepoint synchronization (in this time slot where we often end up yielding the VM thread).
As long as you promise to safepoint and processes them there, if needed, we are not leaking.

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

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