On Mon, 21 Sep 2020 06:13:55 GMT, David Holmes <dhol...@openjdk.org> wrote:
> There is still a lack of motivation for this feature in the JBS issue. What > kind of handshakes need to be asynchronous? > Any async operation implies that the requester doesn't care about when or > even if, the operation gets executed - they > are by definition fire-and-forget actions. So what are the usecases being > envisaged here? Added info in JBS issue: https://bugs.openjdk.java.net/browse/JDK-8238761 All uses-cases of _suspend_flag as initial targets. But some of them require more bits. > Many of the changes included here seem unrelated to, and not reliant on, > async handshakes, and could be factored out to > simplify the review and allow focus on the actual async handshake part e.g. > the JVM TI cleanups seem they could be > mostly standalone. Since I kept rebasing this doing somethings I did somethings to simplify the rebasing. I guess you are talking about the JvmtiHandshakeClosure? > Specific comments below. A general concern I have is where the current thread > is no longer guaranteed to be a > JavaThread (which is a step in the wrong direction in relation to some of the > cleanups I have planned!) and I can't see > why this would be changing. If the VM thread emits a "handshake all" it will continuously loop the JavaThreads until op is completed. We do not keep track which JavaThread have done which handshake. The VM thread will execute all handshakes it finds on every JavaThread's queue. If someone else adds a handshake to one of the JavaThreads the VM thread might execute it. I did not see any issues while looking at the code or in testing doing this. Many of the handshakes used to be safepoints, always executed by VM thread. We changed that to VM thread or JavaThread it self, and we now extend that to any JavaThread. Some of the JVM TI handshakes are a bit different, but since they must proper allocate resource in target JavaThread and not in current JavaThread, there is no issue executing the code with a non-JavaThread. At the moment we have no dependencies on that the 'driver' is a JavaThread for any of the handshakes. We can easily set a per Handshake typ filter (slight changes to Handshake Closure and filter function) and choose to only executed the handshake with target self and requester/any JavaThread/only VM thread. So if we think JVM TI handshakes should only be executed by requester or target it's an easy fix. If you think the default is wrong, it's also an easy change. (For others following there also a planned investigation on requester only executed handshake, which is not as easy) > Thanks. # > src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 320: > >> 318: op.do_thread(_thread); >> 319: } else { >> 320: Handshake::execute(&op, _thread); > > We should still have the guarantee check that the target was alive. Fixed ------------- PR: https://git.openjdk.java.net/jdk/pull/151
