JDK-8223312 : Utilize handshakes instead of is_thread_fully_suspended
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-05-03
  • Updated: 2021-11-09
  • Resolved: 2020-10-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16 b22Fixed
Related Reports
Relates :  
JDK-8265313 - Obsolete the unused AssertOnSuspendWaitFailure and TraceSuspendWaitFailures flags
Relates :  
JDK-8238761 - Asynchronous handshakes
Relates :  
JDK-8223313 - Use handshakes for CountStackFrames.
Relates :  
JDK-8238861 - Remove suspend_flag
Description
Converting all possible use-cases of is_thread_fully_suspended to handshakes will make it easier to implement suspend/resume itself with handshakes.
The use-cases of is_thread_fully_suspended is essentially handshakes but via S/R protocol.
Comments
Changeset: 4634dbef Author: Robbin Ehn <rehn@openjdk.org> Date: 2020-10-22 15:16:50 +0000 URL: https://git.openjdk.java.net/jdk/commit/4634dbef
22-10-2020
Sorry my comment was very confused.
16-06-2020
JVM/TI SuspendThread() does not require a safepoint for the target thread to become suspended. If the target thread happens to notice the external suspend request quickly enough, then the target thread will self-suspend before the suspend requesting thread checks to see if the target's suspend request has completed and the suspend requesting thread will not issue a safepoint request.
15-06-2020
Note that some JVM TI code makes assumptions about suspension and the fact it is currently tied to a safepoint. For example GetObjectMonitorUsage will call JvmtiEnvBase::get_object_monitor_usage which assumes that it can query the suspension state of a thread and know that if it was suspended it cannot be resumed; and if if not suspended it cannot become suspended, because those state changes require a safepoint and the current thread does not go to a safepoint while operating on the monitor related to the target thread.
15-06-2020