RFR: 8266002: vmTestbase/nsk/jvmti/ClassPrepare/classprep001 should skip events for unexpected classes

Chris Plummer cjplummer at openjdk.java.net
Tue Apr 27 23:21:07 UTC 2021


On Tue, 27 Apr 2021 21:30:09 GMT, Alex Menkov <amenkov at 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


More information about the serviceability-dev mailing list