RFR: 8203948: Expand JVMTI callback notion of "internal threads"

[coleen.phillimore at oracle.com]

Looks good to me.
Coleen

On 5/30/18 12:28 PM, Kim Barrett wrote:
> Please review this change to JVMTI to relax some restrictions on where
> some functions may be called.  Presently they are restricted to being
> called from either a Java thread, the VM thread, or a thread for which
> is_ConcurrentGC_thread() returns true (e.g. ConcurrentGCThreads and
> AbstractGangWorkers (if the containing WorkGang is configured as
> concurrent).
>
> We now allow these functions to be called for either a Java thread or
> a Named thread, e.g. any of the VM thread, ConcurrentGCThreads, or
> WorkerThreads.  This allows the restricted functions to be called from
> any WorkerThreads, rather than only AbstractGangWorkers in concurrent
> WorkGangs.
>
> The change to jvmtiEnter.xsl affects the following generated
> functions:
> jvmti_Allocate
> jvmti_Deallocate
> jvmti_CreateRawMonitor
> jvmti_DestroyRawMonitor
> jvmti_RawMonitorEnter
> jvmti_RawMonitorExit
> jvmti_RawMonitorWait
> jvmti_RawMonitorNotify
> jvmti_RawMonitorNotifyAll
> jvmti_GetTimerInfo
> jvmti_GetTime
> jvmti_SetEnvironmentLocalStorage
> jvmti_GetEnvironmentLocalStorage
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8203948
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8203948/open.00/
>
> Testing:
> Mach5 tier{1,2,3} and hs-tier{4,5}
>
> There are no tests that directly exercise the relaxed restrictions
> yet.  We'll start hitting that as part of in-progress work to
> parallelize WeakProcessor, which calls JvmtiExport::weak_oops_do,
> which generates ObjectFree events, which uses the Raw Monitor API.
>