JDK-8203948 : Expand JVMTI callback notion of "internal threads"
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-05-29
  • Updated: 2018-08-30
  • Resolved: 2018-06-05
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 11
11 b17Fixed
Related Reports
Relates :  
JDK-8210131 - vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code
Description
The JVMTI spec says heap callback functions may be invoked on an internal thread or the thread which called the iteration function.  This used to be implemented by requiring the current thread to be either a Java thread or the VM thread.  JDK-6278106 expanded this to also allow ConcurrentGCThreads, to support CMS.

In particular, this affected the Raw Monitor API.  See also JDK-4921421 and JDK-4937789.

In order to support parallelization of the processing of weak references in the VM (e.g. weak but not java.lang.ref.Reference), we want to be able to call JvmtiExport::weak_oops_do from GC worker threads. However, that function attempts to generate ObjectFree events for objects that are found to be dead. Since GC worker thread might not be is_ConcurrentGC_thread, attempting to generate those events can fail (with JVMTI_ERROR_UNATTACHED_THREAD). Adding such GC worker thread to the acceptable set should allow this new configuration to work.
Comments
That's pretty close to where I'm ending up. The WatcherThread is still excluded. There are internal dispatches on whether the current thread is a Java thread or one of the "internal" thread types (previously VM thread or ConcurrentGC thread, expanding to Named thread), because the implementation of (for example) the Raw Monitor stuff is different between those two cases.
30-05-2018
Thanks Kim. I'd missed the restrictions on the ObjectFree and GC Start/Finish events. Seems to me we could just allow any thread to execute these rather than defining a set of allowed threads.
30-05-2018
The callbacks in question are forbidden from calling Java code, and have very restrictive constraints on what they can call, presumably so they can be called from the VM thread, which is one of the permitted contexts.
30-05-2018
Don't callback threads have to be able to execute Java code! ??
30-05-2018
Note that ZGC is already using a WorkGang thread to call JvmtiExport::weak_oops_do. That succeeds kind of by accident, as the ZGC worker threads are configured to be "concurrent" and the same work gang is used for both concurrent and STW processing. Since they are configured as "concurrent", is_ConcurrentGC_thread is true for them, and so JVMTI allows callback invocations from them. This also provides further evidence that the present restriction is unnecessary, since there's very little real difference between worker threads configured as "concurrent" and those which are not (as demonstrated by ZGCs use of them in both contexts).
29-05-2018