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 Robin's comment:

> This line is just confusing, the requesting thread only enters a safepoint if it's a JavaThread.
> ...
> Not sure if this epoch sync is run by a thread part of SuspendibleThreadSet or not, but:

Yes it is confusing. Let me clarify the problem.

The epoch sync is requested by either a G1 refinement thread, which is a part of SuspendibleThreadSet; or a Java thread from its post-write barrier's slow path, which is a JRT_LEAF function that forbids any operation that can safepoint. G1 by design supports concurrent refinement from a Java thread's post-write barrier, if there's too many cards to refine, see G1DirtyCardQueueSet::handle_completed_buffer().

I could get the epoch sync working using synchronous handshake when requesting thread == G1 refinement thread, by leaving SuspendibleThreadSet and redirtying some pending cards before calling Handshake::execute(). However, it does not work for the requesting thread == Java thread case, due to the JRT_LEAF constraint. This is the reason for proposing to use Handshake::enqueue() and support executing them from non-self threads.

> If it is; it is just prolonging the time to safepoint, which is a free epoch, thus finishing the epoch just wastes CPU.

Good point. I'll make sure any waiting in the epoch sync protocol also checks for pending safepoint and yields.

Anyway, I think the arm-the-poll-only approach is superior and it does not need to issue any handshake. I will look into that instead.

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

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