On Tue, 27 Apr 2021 21:30:09 GMT, Alex Menkov <amen...@openjdk.org> wrote:
> Class loading may cause loading of some other system/internal classes (for
> example loading of java.util.concurrent classes when an other thread loads
> some classes concurrently).
> The fix updates ClassPrepare test so it skip events for "unexpected" classes.
> Also it adds a testcase to verify that classes which are explicitly loaded on
> other thread do not generate ClassPrepare event on the test thread.
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?
test/hotspot/jtreg/vmTestbase/nsk/jvmti/ClassPrepare/classprep001/classprep001.cpp
line 65:
> 63: { "Lnsk/jvmti/ClassPrepare/classprep001$TestClass;", EXP_STATUS, 3,
> 2, 1 }
> 64: };
> 65: // This classes are loaded on a different thread.
"These 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.
-------------
Changes requested by cjplummer (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3732
