RFR: 8238761: Asynchronous handshakes [v3]

[Robbin Ehn]

On Mon, 21 Sep 2020 05:01:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed double check, fix comment, removed not needed function, updated logs
>
> src/hotspot/share/prims/jvmtiEventController.cpp line 339:
> 
>> 337:     hs.do_thread(target);
>> 338:   } else {
>> 339:     Handshake::execute(&hs, target);
> 
> We should still have the guarantee check that the target is still alive.

Fixed

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 692:
> 
>> 690:   // calling_thread is the thread that requested the list of monitors for java_thread.
>> 691:   // java_thread is thread owning the monitors.
>> 692:   // current_thread is thread executint this code, can be a non-JavaThread (e.g. VM Thread).
> 
> Where is the use of the VMThread introduced as I cannot see it? The code was changed to use direct handshakes so that
> we know that either the caller or the target (both JavaThreads) must be executing it. I don't see any VMOperation added
> to call this code.

The assumption that it must be an JavaThread was due to code such as "JavaThread::current();", any Thread can execute
this. The default the first thread grabbing the handshake state lock for the targeted thread will execute all handshake
operation it is allowed to. This might be the VM thread.

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

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

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