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

David Holmes david.holmes at oracle.com
Fri May 21 03:50:16 UTC 2021


On 21/05/2021 1:34 pm, Man Cao wrote:
> On Fri, 21 May 2021 02:57:06 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>> 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.
> 
> There's a per-thread epoch counter that determines each thread's progress for an epoch sync request.
> A blocked thread cannot update its epoch counter by itself, so the requesting thread needs to "skip" the blocked thread by first checking if the target thread is blocked, then doing either:
> - treats the target thread's epoch counter as >= the requested counter value;
> - updates the target thread's counter on behalf of the target thread.
> 
> Either approach ensures forward progress when encountering a blocked thread. Otherwise, any blocked thread would prevent the epoch sync from finishing, leading to deferred cards.
> 
> Perhaps the description of https://bugs.openjdk.java.net/browse/JDK-8236485 can help understand it?
> 
> Anyway, this is beyond this PR. What do we want to do with this PR? The epoch sync protocol will not depend on it if it uses the arm-the-poll-only approach.

Without a solid use-case to drive the design decisions it isn't clear to 
me exactly what the current PR should look like. I think until we have 
something that needs and will use this enhanced mechanism then we should 
leave it as-is.

Cheers,
David
-----

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


More information about the hotspot-dev mailing list