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

[Man Cao]

On Tue, 18 May 2021 19:08:08 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
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added missing deallocation and renamed "remote" to "non-self".

Re Robbin's comment:

Yes, if the G1 epoch sync protocol uses async handshake, it should either not to issue too many handshakes that are left unexecuted, or drain all pending handshakes at a safepoint. Currently the implementation does not do that so it could cause leaks.

G1AsyncEpochHandshakeClosure is indeed a no-op, and the protocol only needs the fence. It actually only needs the target thread to execute `G1EpochUpdater::update_epoch_self()` at some point, which contains a StoreStore fence and is sufficient for creating release-acquire edges. I'll try this arm-the-poll-only approach.

What do you think about this change though? It is still a reasonable refactoring that enables more use cases of async handshakes (although not necessarily for G1 epoch sync protocol), right?

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

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