RFR: 8257831: Suspend with handshakes [v3]

Richard Reingruber rrich at openjdk.java.net
Wed Apr 7 14:36:41 UTC 2021


On Wed, 7 Apr 2021 13:33:45 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.cpp line 2102:
>> 
>>> 2100:   do {
>>> 2101:     set_thread_state(_thread_blocked);
>>> 2102:     // Check if _external_suspend was set in the previous loop iteration.
>> 
>> Note that the comment for this method at line 1806 needs updating as it refers to a now deleted method.
>
> I removed that line, not sure if the comment needs additional fixing.

I think David requested updating of the comment for `JavaThread::java_suspend_self_with_safepoint_check()`.

I hope to delete the whole method soon and build on the new suspend mechanism, if Robbin is ok with that. For now I'd like to propose the following:

// Wait for another thread to perform object reallocation and relocking on behalf of
// this thread.
// Raw thread state transition to _thread_blocked and back again to the original
// state before returning are performed. The current thread is required to
// change to _thread_blocked in order to be seen to be safepoint/handshake safe
// whilst suspended and only after becoming handshake safe, the other thread can
// complete the handshake used to synchronize with this thread and then perform
// the reallocation and relocking. We cannot use the thread state transition
// helpers because we arrive here in various states and also because the helpers
// indirectly call this method.  After leaving _thread_blocked we have to check
// for safepoint/handshake, except if _thread_in_native. The thread is safe
// without blocking then. Allowed states are enumerated in
// SafepointSynchronize::block(). See also EscapeBarrier::sync_and_suspend_*()

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

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


More information about the hotspot-runtime-dev mailing list