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

[Daniel D. Daugherty]

On 8/30/18 10: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.
>
> 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/

src/hotspot/share/prims/jvmtiEnter.xsl
     No comments.

test/hotspot/jtreg/ProblemList.txt
     No comments.


I verified that the XSL changes will only affect the two functions
in question: jvmti_GetCurrentThreadCpuTimerInfo() and
jvmti_GetCurrentThreadCpuTime(). Unfortunately, I can't remember
why that bit of XSL code only applies to those two functions.

In any case, thumbs up!

Dan


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