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

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Chris Plummer
Hello,

Please review the following:

https://bugs.openjdk.java.net/browse/JDK-8191229
http://cr.openjdk.java.net/~cjplummer/8191229/webrev.00/

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
Reply | Threaded
Open this post in threaded view
|

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

serguei.spitsyn@oracle.com
Hi Chris,

It looks good to me.
I wonder if we have other similar cases like this in the JVMTI tests.

Thanks,
Serguei


On 12/6/17 14:38, 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/
>
> 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

Reply | Threaded
Open this post in threaded view
|

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

Chris Plummer
I didn't see any other suspicious uses of FindClass in the jvmti jtreg
tests.

Chris

On 12/6/17 3:33 PM, [hidden email] wrote:

> Hi Chris,
>
> It looks good to me.
> I wonder if we have other similar cases like this in the JVMTI tests.
>
> Thanks,
> Serguei
>
>
> On 12/6/17 14:38, 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/
>>
>> 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
>

Reply | Threaded
Open this post in threaded view
|

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

serguei.spitsyn@oracle.com

On 12/6/17 15:55, Chris Plummer wrote:
> I didn't see any other suspicious uses of FindClass in the jvmti jtreg
> tests.

Good to know.
There are not that many jvmti jtreg tests.
Interesting part would be the nsk.jvmti tests.
There are many uses of the FindClass there.
But let's keep it out of this review.

Thanks,
Serguei


> Chris
>
> On 12/6/17 3:33 PM, [hidden email] wrote:
>> Hi Chris,
>>
>> It looks good to me.
>> I wonder if we have other similar cases like this in the JVMTI tests.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 12/6/17 14:38, 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/
>>>
>>> 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
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Chris Plummer
On 12/6/17 4:10 PM, [hidden email] wrote:

>
> On 12/6/17 15:55, Chris Plummer wrote:
>> I didn't see any other suspicious uses of FindClass in the jvmti
>> jtreg tests.
>
> Good to know.
> There are not that many jvmti jtreg tests.
> Interesting part would be the nsk.jvmti tests.
> There are many uses of the FindClass there.
> But let's keep it out of this review.
Yes, I did check there and noticed too many calls to go through. We'll
just need to keep an eye out for new failures since this failure seems
to have been triggered by recent JDK or VM changes resulting in a
contended monitor that we did not see in past.

Chris

>
> Thanks,
> Serguei
>
>
>> Chris
>>
>> On 12/6/17 3:33 PM, [hidden email] wrote:
>>> Hi Chris,
>>>
>>> It looks good to me.
>>> I wonder if we have other similar cases like this in the JVMTI tests.
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 12/6/17 14:38, 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/
>>>>
>>>> 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
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Alex Menkov-2
In reply to this post by serguei.spitsyn@oracle.com
+1

Chris, while you are there could you please fix a minor issue with the
native part of the test - Agent_Initialize doesn't zero callbacks struct
(only sets MonitorContendedEnter/MonitorContendedEntered):

-    jvmtiEventCallbacks callbacks;
+    jvmtiEventCallbacks callbacks = {0};

--alex

On 12/06/2017 15:33, [hidden email] wrote:

> Hi Chris,
>
> It looks good to me.
> I wonder if we have other similar cases like this in the JVMTI tests.
>
> Thanks,
> Serguei
>
>
> On 12/6/17 14:38, 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/
>>
>> 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
>
Reply | Threaded
Open this post in threaded view
|

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

Chris Plummer
Hi Alex,

Good catch. I guess it doesn't blow up because we only enable the two
callbacks we setup. It looks like we usually zero it out with:

     memset(&callbacks, 0, sizeof(callbacks));

So I'll go with that fix.

thanks,

Chris

On 12/6/17 4:48 PM, Alex Menkov wrote:

> +1
>
> Chris, while you are there could you please fix a minor issue with the
> native part of the test - Agent_Initialize doesn't zero callbacks
> struct (only sets MonitorContendedEnter/MonitorContendedEntered):
>
> -    jvmtiEventCallbacks callbacks;
> +    jvmtiEventCallbacks callbacks = {0};
>
> --alex
>
> On 12/06/2017 15:33, [hidden email] wrote:
>> Hi Chris,
>>
>> It looks good to me.
>> I wonder if we have other similar cases like this in the JVMTI tests.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 12/6/17 14:38, 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/
>>>
>>> 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
>>


Reply | Threaded
Open this post in threaded view
|

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

David Holmes
In reply to this post by Chris Plummer
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.

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
Reply | Threaded
Open this post in threaded view
|

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

Chris Plummer
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().

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


Reply | Threaded
Open this post in threaded view
|

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

David Holmes
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.

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
>
>
Reply | Threaded
Open this post in threaded view
|

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


Reply | Threaded
Open this post in threaded view
|

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

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


Reply | Threaded
Open this post in threaded view
|

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

Chris Plummer
New webrev:

https://bugs.openjdk.java.net/browse/JDK-8191229
http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/

testClass now initialized from JNI_OnLoad(), and use memset to clear
callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv().

thanks,

Chris
Reply | Threaded
Open this post in threaded view
|

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

serguei.spitsyn@oracle.com
In reply to this post by David Holmes
Hi David,


On 12/6/17 18:47, 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 see no point to initialize it specifically in the JNI_OnLoad except
for a simplicity.
We just need the testClass set before the locks in the test class are used.
But I see no problem in either case. :)

Thanks,
Serguei


> 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

Reply | Threaded
Open this post in threaded view
|

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

serguei.spitsyn@oracle.com
In reply to this post by Chris Plummer
Hi Chris,

This variant is not that simple as one would expect but it looks Ok to me.

Thanks,
Serguei


On 12/6/17 23:44, Chris Plummer wrote:

> New webrev:
>
> https://bugs.openjdk.java.net/browse/JDK-8191229
> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/
>
> testClass now initialized from JNI_OnLoad(), and use memset to clear
> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv().
>
> thanks,
>
> Chris

Reply | Threaded
Open this post in threaded view
|

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

Chris Plummer
I could put it in Agent_Initialize(). It would be a little simpler since
I would not need to call and error check GetEnv() again. I initially had
done it there, but ran into the crash due to handle issues, so I moved
it to JNI_OnLoad. But ended up having the same problem there, and it was
due to specifying JVMTI_VERSION_1 on the GetEnv() call. I think possibly
the dispatch table is different and it was not doing the NewGlobalRef()
call properly. So Agent_Initialize() might work now that I'm specifying
JVMTI_VERSION_9.

thanks,

Chris

On 12/7/17 12:02 AM, [hidden email] wrote:

> Hi Chris,
>
> This variant is not that simple as one would expect but it looks Ok to
> me.
>
> Thanks,
> Serguei
>
>
> On 12/6/17 23:44, Chris Plummer wrote:
>> New webrev:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8191229
>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/
>>
>> testClass now initialized from JNI_OnLoad(), and use memset to clear
>> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv().
>>
>> thanks,
>>
>> Chris
>

Reply | Threaded
Open this post in threaded view
|

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

David Holmes
In reply to this post by Chris Plummer
Hi Chris,

On 7/12/2017 5:44 PM, Chris Plummer wrote:
> New webrev:
>
> https://bugs.openjdk.java.net/browse/JDK-8191229
> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/
>
> testClass now initialized from JNI_OnLoad(), and use memset to clear
> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv().

   71         // JNI_OnLoad has not been called yet, so can't possibly
be an instance of TEST_CLASS.

You can't be executing this method before JNI_OnLoad has executed. If
JNI_Onload has executed then you can't execute this method and find NULL
as that means JNI_Onload failed and hence library loading fails and so
you can't be executing this method. So this method reduces to a simple
instanceof check, which can go straight into the calling method.

  183     if (testClass == NULL) {

That can just be "else {" - but as I said it can't be NULL anyway.

Thanks,
David

> thanks,
>
> Chris
Reply | Threaded
Open this post in threaded view
|

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

Yasumasa Suenaga-4
In reply to this post by Chris Plummer
Hi Chris,

I added testcase of GetOwnedMonitorInfo in JDK-8185164.
I have concern your change to cache the result of FindClass().

According to [1], FindClass() calls find_class_from_class_loader(), it returns JNI local value.
Is it safe to cache?

So I called FindClass each time in original commit.


Thanks,

Yasumasa


[1] http://hg.openjdk.java.net/jdk/hs/file/32fd4be602d5/src/hotspot/share/prims/jvm.cpp#l3450


On 2017/12/07 16:44, Chris Plummer wrote:

> New webrev:
>
> https://bugs.openjdk.java.net/browse/JDK-8191229
> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/
>
> testClass now initialized from JNI_OnLoad(), and use memset to clear
> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv().
>
> thanks,
>
> Chris
>
Reply | Threaded
Open this post in threaded view
|

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

Chris Plummer
In reply to this post by David Holmes
On 12/7/17 2:41 AM, David Holmes wrote:

> Hi Chris,
>
> On 7/12/2017 5:44 PM, Chris Plummer wrote:
>> New webrev:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8191229
>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/
>>
>> testClass now initialized from JNI_OnLoad(), and use memset to clear
>> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv().
>
>   71         // JNI_OnLoad has not been called yet, so can't possibly
> be an instance of TEST_CLASS.
>
> You can't be executing this method before JNI_OnLoad has executed. If
> JNI_Onload has executed then you can't execute this method and find
> NULL as that means JNI_Onload failed and hence library loading fails
> and so you can't be executing this method. So this method reduces to a
> simple instanceof check, which can go straight into the calling method.
That's what I thought, but it was crashing because testClass was NULL. I
think Agent_OnLoad() is being called before JNI_OnLoad. I'll add traces
and see for sure.

Chris

>
>  183     if (testClass == NULL) {
>
> That can just be "else {" - but as I said it can't be NULL anyway.
>
> Thanks,
> David
>
>> thanks,
>>
>> Chris



Reply | Threaded
Open this post in threaded view
|

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

Chris Plummer
In reply to this post by Yasumasa Suenaga-4
Hi Yasumasa,

It is safe in my version because I move it to a global ref. See the
NewGlobalRef() call in my webrev.

thanks,

Chris

On 12/7/17 6:14 AM, Yasumasa Suenaga wrote:

> Hi Chris,
>
> I added testcase of GetOwnedMonitorInfo in JDK-8185164.
> I have concern your change to cache the result of FindClass().
>
> According to [1], FindClass() calls find_class_from_class_loader(), it
> returns JNI local value.
> Is it safe to cache?
>
> So I called FindClass each time in original commit.
>
>
> Thanks,
>
> Yasumasa
>
>
> [1]
> http://hg.openjdk.java.net/jdk/hs/file/32fd4be602d5/src/hotspot/share/prims/jvm.cpp#l3450
>
>
> On 2017/12/07 16:44, Chris Plummer wrote:
>> New webrev:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8191229
>> http://cr.openjdk.java.net/~cjplummer/8191229/webrev.01/
>>
>> testClass now initialized from JNI_OnLoad(), and use memset to clear
>> callbacks. Also updated to use JVMTI_VERSION_9 when calling GetEnv().
>>
>> thanks,
>>
>> Chris
>>

12