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

[David Holmes]

On 21/05/2021 12:18 pm, Man Cao wrote:
> 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 David's comment:
> 
>> Still not clear why this is necessary. The target thread is just as
>> blocked or in native during a GC pause safepoint, as it is during a
>> handshake. So if the GC can process them in one case surely it can do
>> both. ??
> 
> There is no association between a dirty card and Java thread(s). Even if we have such association, i.e. we track which thread produced the dirty card, it is still insufficient to coordinate with only the dirtying thread. This is because other threads could have observed the card being dirty and performed a store to Java heap, without doing any fence or synchronization. Later, the refinement thread (the requesting thread) needs to load from the Java heap range mapped to the dirty card's address for the refinement work.
> Thus, it is only safe to load from the Java heap range under one of the two conditions:
> - The requesting thread has finished epoch synchronization with **all** Java threads.
> - It is at a safepoint where **all** Java threads have been synchronized and stopped.
> 
> Either condition guarantees that previous stores to the Java heap range mapped to the card's address are visible to the loading thread.

If it is an all or none proposition then I don't see what skipping 
blocked threads has to do with this ??? Sorry I think I'm losing track 
of issues.

David


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