RFR(XS): VM times out in VM_HandshakeAllThreads::doit() with RunThese30M
Robbin Ehn
robbin.ehn at oracle.com
Wed Aug 15 09:13:14 UTC 2018
Hi all, please review.
The issue is that external suspend don't set the thread state to blocked. The
safepoint code handles this internally but, as handshakes do, using e.g.
safepoint_safe() this was not handled. External suspending a thread causes the
handshake not to come through until you resume that thread (bad for ZGC).
The proper fix (at least IMHO) to this is to implement suspend (and the other
uses of suspend_flag) with handshakes instead, but that will require asynch
handshakes and would require all platforms to implement handshakes (or they
would suffer a safepoint). So if you read this have a platform which you do not
have implemented handshakes for, please start looking into it.
Below patch adds the unhandle case for handshakes.
Bug: https://bugs.openjdk.java.net/browse/JDK-8207334
Passed tier 1-5 and I could no longer get prolonged handshakes due to suspend.
Thanks, Robbin
diff -r f3cf91d5373f src/hotspot/share/runtime/handshake.cpp
--- a/src/hotspot/share/runtime/handshake.cpp Mon Aug 13 14:04:43 2018 +0200
+++ b/src/hotspot/share/runtime/handshake.cpp Wed Aug 15 11:00:22 2018 +0200
@@ -340,3 +340,8 @@
bool HandshakeState::vmthread_can_process_handshake(JavaThread* target) {
- return SafepointSynchronize::safepoint_safe(target, target->thread_state());
+ // We must block the S/R protocol to resume a thread while the vm thread
+ // is executing the operation, by holding the Threads_lock.
+ // This is problematic, since we now can't remove the Threads_lock in handshakes.
+ assert(Threads_lock->owned_by_self(), "Not holding Threads_lock.");
+ return SafepointSynchronize::safepoint_safe(target, target->thread_state()) ||
+ target->is_ext_suspended();
}
More information about the hotspot-runtime-dev
mailing list