RFR: 8238761: Asynchronous handshakes [v5]

[David Holmes]

On 23/09/2020 7:37 pm, Robbin Ehn wrote:
> On Wed, 23 Sep 2020 02:56:00 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    Update after Coleen
>>
>> src/hotspot/share/runtime/handshake.hpp line 97:
>>
>>> 95:   }
>>> 96:   bool block_for_operation() {
>>> 97:     return !_queue.is_empty() || _lock.is_locked();
>>
>> I really don't understand the is_locked() check in this condition. ??
>> And the check for !empty is racy, so how do we avoid missing an in-progress addition?
> 
> A JavaThread is blocked.
> A second thread have just executed a handshake operation for this JavaThread and are on line:
> https://github.com/openjdk/jdk/blob/cd784a751a3153939b9284898f370160124ca610/src/hotspot/share/runtime/handshake.cpp#L510
> And the queue is empty.
> 
> The JavaThread wakes up and changes state from blocked to blocked_trans.
> It now checks if it's allowed to complete the transition to e.g. vm.
> 
> If a third thread adds to queue before the second thread leaves the loop it's operation can be executed.
> But the JavaThread could see the queue as empty. (racey as you say)
> 
> The executor takes lock and then checks if the JavaThread is safe for processing.
> The JavaThread becomes unsafe and then check if lock is locked.
> If the lock is locked we must take slow path to avoid this.
> 
> We should also take slow path if there is something on queue to processes.
> We are unsafe when we check queue and lock is not held, if we 'miss' that anything is on queue, it's fine.
> Since any other thread cannot have seen us as safe and seen the item on queue. (since lock is not held)
> Thus not allowed to process the operation.


Wow! That all definitely needs some detailed commentary.

Thanks,
David
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/151
>