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

[David Holmes]

Hi Kim,

On 31/08/2018 12:15 PM, Kim Barrett wrote:
> 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.

As previously discussed** we could just relax the thread constraint 
completely here. For most JVM TI callbacks the caller must be a 
JavaThread, but for callbacksafe cases it can nominally be any thread.

I don't like the fact NamedThread is getting used to imply a capability 
that is totally unrelated to being named.

**Though if you saw my initial comment on the bug you'll also realize I 
can't make up my mind whether to enumerate allowed threads or not. :)

Cheers,
David

> 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.
>