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

[Alex Menkov]

+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, serguei.spitsyn at oracle.com 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
>