On 12/6/17 8:04 PM, Chris Plummer wrote:
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.
Interesting. The problem was passing JVMTI_VERSION_1 into GetEnv()
instead of JNI_VERSION_1_8. I'm not sure why that was problematic, but
changing it to JNI_VERSION_1_8 fixed the problem. I had copied this
GetEnv() code from Agent_Initialize(), but there it was used to get the
jvmtiEnv*, and seemed to be working ok, at least for the use of the
jvmtiEnv* in that function. The other jvmti tests are using
JVMTI_VERSION_9, but I think most of them are new in 9. I don't know
when GetOwnedMonitorInfo was introduced, but maybe it should also be
updated to specify JVMTI_VERSION_9.
Chris
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
