On 6/28/19 2:09 PM, serguei.spit...@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.
Looks good.
Thumbs up.
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
