On Mon, 14 Sep 2020 13:00:59 GMT, Robbin Ehn <r...@openjdk.org> wrote:
> This patch implements asynchronous handshake, which changes how handshakes > works by default. Asynchronous handshakes > are target only executed, which they may never be executed. (target may block > on socket for the rest of VM lifetime) > Since we have several use-cases for them we can have many handshake pending. > (should be very rare) To be able handle an > arbitrary amount of handshakes this patch adds a per JavaThread queue and > heap allocated HandshakeOperations. It's a > singly linked list where you push/insert to the end and pop/get from the > front. Inserts are done via CAS on first > pointer, no lock needed. Pops are done while holding the per handshake state > lock, and when working on the first > pointer also CAS. The thread grabbing the handshake state lock for a > JavaThread will pop and execute all handshake > operations matching the filter. The JavaThread itself uses no filter and any > other thread uses the filter of everything > except asynchronous handshakes. In this initial change-set there is no need > to do any other filtering. If needed > filtering can easily be exposed as a virtual method on the HandshakeClosure, > but note that filtering causes handshake > operation to be done out-order. Since the filter determins who execute the > operation and not the invoked method, there > is now only one method to call when handshaking one thread. Some comments > about the changes: > - HandshakeClosure uses ThreadClosure, since it neat to use the same closure > for both alla JavThreads do and Handshake > all threads. With heap allocating it cannot extends StackObj. I tested > several ways to fix this, but those very much > worse then this. > > - I added a is_handshake_safe_for for checking if it's current thread is > operating on itself or the handshaker of that > thread. > > - Simplified JVM TI with a JvmtiHandshakeClosure and also made them not > needing a JavaThread when executing as a > handshaker on a JavaThread, e.g. VM Thread can execute the handshake > operation. > > - Added WB testing method. > > - Removed VM_HandshakeOneThread, the VM thread uses the same call path as > direct handshakes did. > > - Changed the handshake semaphores to mutex to be able to handle deadlocks > with lock ranking. > > - VM_HandshakeAllThreadsis still a VM operation, since we do support half of > the threads being handshaked before a > safepoint and half of them after, in many handshake all operations. > > - ThreadInVMForHandshake do not need to do a fenced transistion since this is > always a transistion from unsafe to unsafe. > > - Added NoSafepointVerifyer, we are thinking about supporting safepoints > inside handshake, but it's not needed at the > moment. To make sure that gets well tested if added the NoSafepointVerifyer > will raise eyebrows. > > - Added ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); due > to the NoSafepointVerifyer. > > - Added filtered queue and gtest for it. > > Passes multiple t1-8 runs. > Been through some pre-reviwing. > src/hotspot/share/prims/jvmtiThreadState.cpp > src/hotspot/share/prims/jvmtiEnvBase.cpp Removed double checks. > src/hotspot/share/runtime/handshake.cpp > ... > I would just leave ProcessResult as an enum and log as before. Reverted to plain enum and updated logs. (better?) > src/hotspot/share/runtime/handshake.cpp > 387: NoSafepointVerifier nsv; > 388: process_self_inner(); I wanted a NSV to cover the process_self_inner method. So I added a second one in suggested place: > NoSafepointVerifier nsv; > _handshake_cl->do_thread(thread); > } > src/hotspot/share/runtime/interfaceSupport.inline.hpp > 156: // Threads shouldn't block if they are in the middle of > printing, but... > 157: ttyLocker::break_tty_lock_for_safepoint(os::current_thread_id()); > What's the issue of having NoSafepointVerifier inside the handshake? Sorry, the issue is the lock rank. Right now the semaphore hides this issue. Please see commit 86b83d0. ------------- PR: https://git.openjdk.java.net/jdk/pull/151
