RFR(S): 8191229: serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java fails with NoClassDefFoundError

[Chris Plummer]

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
>>
>>