On 29/04/2021 5:21 am, Alex Menkov wrote:
On Tue, 27 Apr 2021 23:15:35 GMT, Chris Plummer <[email protected]> wrote:
I don't see any mention in the CR of the test failing due to this issue. How
was it discovered? How is the fix being verified?
I discovered it researching JCK failure on a platform with UsageTracker enabled.
JCK test does exactly the same as this test, but I was not able to reproduce
the failure for this test (but this is a race, so that's normal)
I ensured the fix works during development when created otherTread before
getReady and had printdump on.
otherTread -> otherThread ?
Cheers,
David
-----
It produced a lot of ClassPrepare event for Thread and lambda-related classes.
test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassPrepare/classprep001/classprep001.cpp
line 292:
290:
291: JNIEXPORT void JNICALL
292: Java_nsk_jvmti_ClassPrepare_classprep001_getReady(JNIEnv *env, jclass cls,
jthread thread) {
It's not clear to me why you now pass in the thread instead of calling
GetCurrentThread, when the thread passed in is still always the current thread.
Same thing for the `check()` method.
I think it makes the code more flexible and easier to extend
-------------
PR: https://git.openjdk.java.net/jdk/pull/3732