On 12/6/17 7:38 PM, David Holmes wrote:
On 7/12/2017 1:08 PM, Chris Plummer wrote:
On 12/6/17 6:47 PM, David Holmes wrote:
Hi Chris,
On 7/12/2017 8:38 AM, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8191229
http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/
I expected to see the initialization done in JNI_OnLoad, not in a
new init() method.
I was worried it wouldn't work because of JDK-8188052, but I guess
that only impacts JNI_OnUnload. I can change it to init from
JNI_OnLoad().
Yes please use JNI_OnLoad.
Having issues with that. The IsInstanceOf() done during the jvmti
callback is crashing in JNIHandles::resolve_non_null(). Something is
messed up about the testclass handle, but I can't figure out what. I'm
initializing it the same way, except in OnLoad() rather than in init().
JNIEXPORT jint JNICALL
JNI_OnLoad(JavaVM *jvm, void *reserved) {
jint res;
JNIEnv *env;
res = JNI_ENV_PTR(jvm)->GetEnv(JNI_ENV_ARG(jvm, (void **) &env),
JVMTI_VERSION_1);
testClass = (*env)->FindClass(env, TEST_CLASS);
if (testClass != NULL) {
testClass = (*env)->NewGlobalRef(env, testClass);
}
return JNI_VERSION_1_8;
}
Very strange.
Chris
Thanks,
David
Chris
David
-----
The test is testing contended monitor support. After registering
the callback, it gets an unexpected notification of a contended
monitor, which is happening while the finalizer thread is running.
In the callback the test does a FindClass to find a test class, but
the classloader context is not correct when the finalizer thread is
current, so FindClass fails and leaves an exception pending
(probably blowing away the finalzer thread) and also (separately)
causes the test to fail. It's unknown why this callback is suddenly
being triggered, but the callback itself is not a bug, and the test
needs to defend against it.
The fix is to lookup the test class during test initialization and
keep it cached, rather than look it up every time there is a
contended monitor callback.
thanks,
Chris
