RFR: 8238761: Asynchronous handshakes [v3]
David Holmes
dholmes at openjdk.java.net
Wed Sep 23 04:13:05 UTC 2020
On Mon, 21 Sep 2020 11:07:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
>> src/hotspot/share/runtime/handshake.hpp line 44:
>>
>>> 42: // by the target JavaThread itself or, depending on whether the operation is
>>> 43: // a single target/direct handshake or not, by the JavaThread that requested the
>>> 44: // handshake or the VMThread respectively.
>>
>> This comment now indicates that all single target handshakes are executed as direct-handshakes and never by the
>> VMThread - is that correct?
>
> The concept of direct handshake do not exist in that way. (but can easily be implemented using the filter)
> You have operation that you need to be executed on a JavaThread, you add that to that JavaThread.
> Any thread ("driver") that succeed to claim that JavaThreads handshake state (lock and that JavaThread is safe) procced
> to execute from that handshake queue until empty (empty according to applied filter on queue).
I think the entire comment block above can now be simplified:
// A handshake closure is a callback that is executed for a JavaThread
// while it is in a safepoint/handshake-safe state. Depending on the
// nature of the closure, the callback may be executed by the initiating
// thread, the target thread, or the VMThread. If the callback is not executed
// by the target thread it will remain in a blocked state until the callback completes.
>> src/hotspot/share/runtime/handshake.cpp line 230:
>>
>>> 228: log_trace(handshake)("Threads signaled, begin processing blocked threads by VMThread");
>>> 229: HandshakeSpinYield hsy(start_time_ns);
>>> 230: int executed_by_driver = 0;
>>
>> driver?? Isn't this still the VMThread?
>
> The driver is VM thread or a JavaThread.
But this is VM_HandshakeAllThreads (a VM_Operation), it can't be executed by anything other than the VMThread!
-------------
PR: https://git.openjdk.java.net/jdk/pull/151
More information about the serviceability-dev
mailing list