Description
While discussing solutions for "8213834: JVMTI ResourceExhausted should not be posted in CompilerThread" (see [1]) a more general way to express the ability of a Thread to be able to send JVMTI events was proposed.
a new "virtual bool Thread::can_post_JVMTI_events();" property could, similar to can_call_java(), suppress all kinds of JVMTI events from certain threads.
Open questions:
Which events? For a few JVMTI events the JVMTI documentation already restricts handlers to "not use JNI functions and must not use JVM TI functions except those which specifically allow such use" (see e.g. ObjectFree at [2]). Should we take this into account and not suppress these events?
Which Threads? Does the ability to send JVMTI events from threads have to be documented in the JVMTI spec? If yes, that needs to be done before this RFE is implemented.
[1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-November/025911.html
[2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#ObjectFree
a new "virtual bool Thread::can_post_JVMTI_events();" property could, similar to can_call_java(), suppress all kinds of JVMTI events from certain threads.
Open questions:
Which events? For a few JVMTI events the JVMTI documentation already restricts handlers to "not use JNI functions and must not use JVM TI functions except those which specifically allow such use" (see e.g. ObjectFree at [2]). Should we take this into account and not suppress these events?
Which Threads? Does the ability to send JVMTI events from threads have to be documented in the JVMTI spec? If yes, that needs to be done before this RFE is implemented.
[1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-November/025911.html
[2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#ObjectFree
Attachments
Issue Links
- relates to
-
JDK-8213834 JVMTI ResourceExhausted should not be posted in CompilerThread
- Resolved