RFR: 8210131: vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code

[Kim Barrett]

Please review this small change to GetCurrentThreadCpuTimerInfo and
GetCurrentThreadCpuTime JVMTI operations, allowing them to be called
from any NamedThread.  This is consistent with the behavior from
JDK-8203948; there is no obvious reason for these operations to have
any thread context restriction.

These functions are documented as being callable from heap callbacks
like ObjectFree, which can be called from an "internal thread or the
thread that called the [heap] iteration function".  However, unlike
other, similar functions, these two were requiring the current thread
to be either a JavaThread or the VMThread.  For other such functions,
JDK-6278106 had added Concurrent GC threads, and JDK-8203948
generalized that to any NamedThread (or JavaThread).  This change
makes these functions behave similarly.

This is needed to allow such callbacks to be invoked from a GC worker
thread, such as is now done for G1 (JDK-8072498), and probably other
collectors in the future.  (See comments for JDK-8203948 for a
discussion of why ZGC didn't run into this problem.)

This change also removes the failing test from the problem list.

CR:
https://bugs.openjdk.java.net/browse/JDK-8210131

Webrev:
http://cr.openjdk.java.net/~kbarrett/8210131/open.00/

Testing:
mach5 tier1-3, hs-tier4-6.
Local (linux-x64) jtreg:hotspot_gc, and manually ran the failing test.
Examined the generated jvmtiEnter[Trace].cpp file and verified the
change to the generated code was as expected.