(13) RFR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE)
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Fri Jun 28 22:52:19 UTC 2019
On 6/28/19 12:33 PM, Daniel D. Daugherty wrote:
> On 6/28/19 2:09 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review a test bug fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8226917
>>
>> Webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/
>>
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC04/tc04t001/tc04t001.cpp
>
> old L129: if
> (!NSK_JVMTI_VERIFY(jvmti->GetObjectMonitorUsage(obj, &usageInfo))) {
> old L131: } else if (usageInfo.owner != NULL) {
> old L132: if
> (!NSK_JVMTI_VERIFY(jvmti->InterruptThread(usageInfo.owner)))
> This construct in the old code is racy anyway. Just because the
> GetObjectMonitorUsage() returns information that the object is
> locked by the owner field does not mean that the owner thread
> hasn't exited the lock (and left the building) by the time the
> the InterruptThread() call is made. I suspect they were trying
> to get the owner thread out of the sleep, but they never should
> have checked the result of that call.
Yes, they wanted to get the owner thread out of the sleep.
And it is racy. There was pretty big timeout before to make it more
reliable.
Thanks,
Serguei
>
> Looks good.
>
> Thumbs up.
>
Thanks a lot, Dan!
Serguei
> Dan
>
>
>>
>>
>> Summary:
>> One more fragment in the native agent was overlooked and is not
>> needed anymore
>> after the fix of JDK-8223736 which implemented more reliable sync
>> approach.
>> The error code JVMTI_ERROR_THREAD_NOT_ALIVE started to be seen because
>> the sleep timeout changed to be shorter. Now, the thread holding
>> the monitor
>> is able to notice the enterEventsCount was increased by the
>> MonitorContendedEnter
>> event callback and finish before the callback attempts to interrupt
>> it with the
>> JVMTI InterruptThread.
>>
>>
>> Testing:
>> A mach5 submission is in progress.
>>
>> Thanks,
>> Serguei
>
More information about the serviceability-dev
mailing list