JDK-8220468 : Provide a way to hide/mute "system threads" when working with JVMTI API.
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 13
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-03-11
  • Updated: 2024-07-15
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 25
25Unresolved
Related Reports
Relates :  
JDK-8218812 - vmTestbase/nsk/jvmti/GetAllThreads/allthr001/TestDescription.java failed
Description
With Graal on JVMTI clients start seeing JVMCI compiler threads and get notified about events these threads post and breakpoints they hit, that makes the debugging experience quite complicated comparing to the case when Graal is off. It would be useful if by default JVMTI hid/ignored/muted JVMCI compiler threads (and probably some other "system" threads) and provided a way for JVMTI client  to "unmute" these threads when required.
Comments
In the future, more parts of the JVM might be written in Java. For example, verification. Currently, there are other parts that are in Java, but might be desirable to be hidden, such as class loading, or running static initializers. So in addition to threads, we might want to consider hiding based on module, package, class, method, or even the caller context (so any calls that the caller makes are transitively hidden). (The caller context could be simulated by asking a hidden thread to do the work, or with Project Loom, creating a "hidden" Continuation to do the work.)
12-03-2019
JVM TI (and JMX) already has an internal notion of "hidden" threads, but it seems somewhat ad-hoc and is not under user control. JavaThread::is_hidden_from_external_view() is true for: - the Service Thread - the CodeCacheSweeperThread - "native" compiler threads (the condition being whether they can_call_java()) - hence JVMCI/Graal threads are not hidden While there may be cases where the user may want to include JVMCI threads, in general we would not want to make all these VM threads visible, so we need something more fine-grained than simply a notion of "system thread". Perhaps a general ability to include/exclude specific threads may be the way to go, with JVMCI/Graal then exposing a means to include/exclude its threads based on user request (possibly even dynamically). However it may get complicated as users may want even more fine-grained control, such as the ability to see a thread but not have that thread generate events, for example.
11-03-2019