JDK-8201641 : JVMTI: GetThreadListStackTraces should use Thread-Local Handshakes
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Priority: P4
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2018-04-17
  • Updated: 2023-08-23
  • Resolved: 2023-08-23
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
16Resolved
Related Reports
Blocks :  
JDK-8240918 - [REDO] Allow direct handshakes without VMThread intervention
Relates :  
JDK-8238585 - JvmtiEventControllerPrivate::enter_interp_only_mode() should not make compiled methods on stack not_entrant
Relates :  
JDK-8246206 - Thread.getStackTrace has performance linear in the number of threads
Sub Tasks
JDK-8242425 :  
JVMTI monitor operations should use Thread-Local Handshakes - Resolved
JDK-8242427 :  
JVMTI frame pop operations should use Thread-Local Handshakes - Resolved
JDK-8242428 :  
JVMTI thread operations should use Thread-Local Handshake - Resolved
JDK-8248362 :  
JVMTI frame operations should use Thread-Local Handshake - Resolved
Description
GetThreadListStackTraces should use Thread-Local Handshakes at least when number of threads is one.
Requested by dynatrace.
Comments
All subtasks has been done. I close this issue.
05-09-2020
But be careful that any solution works regardless of which thread executes the handshake - see JDK-8247248.
09-06-2020
See also JDK-8246206 - which also requests optimising for the case of a single-thread with getStackTrace(), as that is the worst-case performance with safepoints.
08-06-2020
Yes this can only use a handshake when interacting with a single-thread. There is an expectation that stacktraces are from the same point in time, with all threads frozen at that point.
09-04-2020
Please note that there is a semantic difference taking samples in a safepoint and in handshakes, if there are mutiple thread sampled. With a safepoint; stacktraces are taken from the same exact moment (from a Java mutation perspective). But with handshake we can have mutation between the samples, consider: Thread A enters a mutual exclusive region, and get sampled inside that region. Thread A leaves the mutual exclusive region. Thread B enter the same mutual exclusive region, and get sampled inside that region. When looking at the stack-traces, we have have two thread inside the same mutual exclusive region. If you are not aware on how the sampling mechanism works, this could be confusing.
09-04-2020
In addition, I think we should use Thread-Local Handshakes in other VMOp for JVMTI in below: class VM_GetCurrentLocation class VM_EnterInterpOnlyMode class VM_UpdateForPopTopFrame class VM_SetFramePop class VM_GetOwnedMonitorInfo class VM_GetCurrentContendedMonitor class VM_GetFrameCount class VM_GetFrameLocation Many JVMTI functions uses VM Operation to get information. However some of them need to stop only one thread - they don't need to stop all threads. It is example for GetOneCurrentContendedMonitor(). http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/ I've started the discussion for this in serviceability-dev: https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html
01-04-2020
Please provide more information about this request - related issue links, feature wiki pages, discussion, motivation behind the request, etc.
11-07-2018