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".

Thanks. Let me first do more experiment to validate first. I'll close this PR once confirming the other approach also works.

> If someone keeps suspending ad resuming a thread the thread might always have the poll armed and always have a handshake.
> Just looking if queue is empty or not, or poll is armed or not can have pathological cases.

If I understand the context correctly, the approach of updating the epoch counter in `process_if_requested_slow()` will prevent the pathological cases above? And yes, the current implementation already updates the epoch counter in `SafepointMechanism::update_poll_values()` similarly.

> If you add an epoch counter into Thread::gc_data_offset you could update it by putting a line next cross-mod-fence:
> `void SafepointMechanism::process_if_requested_slow(JavaThread *thread) { ... OrderAccess::cross_modify_fence(); Universe::heap()->barrier_complete(thread); // store global epoch to GCThreadLocalData }`

Thanks, adding a new virtual method in CollectedHeap is much cleaner than my current `if (UseG1GC) update_epoch_self();` approach.

> But as David said, you basically trying to handshake without a handshake :)
> (should try to put the counter inside the handshake instead)

One note is that a thread could also update its epoch counter in places that are irrelevant to polling or handshake. This could make epoch sync more responsive than handshakes. Currently I only added such update in `ThreadInVMfromJava`, since it is executed frequently. I'll evaluate whether this update still makes much difference in responsiveness.

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

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