Sleeps don't scale under load. That said, I agree with Chris that
the code is already in place. One possible addition is to scale
the sleep value by the timeout factor for the test. That will
further reduce the likelihood of intermittent failures.
Dan
On 10/4/18 7:39 AM, Gary Adams wrote:
Oops, wrong comment used in the patch.
Fresh patch attached.
On 10/4/18, 7:11 AM, Gary Adams wrote:
Patch attached.
I think one reviewer is sufficient for a trivial patch.
On 10/3/18, 4:49 PM, Chris Plummer wrote:
Hi Gary,
Although I don't like relying on timer delays for stuff like this,
the code for it is already in place, so I'm ok with making the delay
longer to make sure there is contention on the monitor. Could you
update the comment to read "// pause to provoke contention on
thread.endingMonitor"
thanks,
Chris
On 10/3/18 11:55 AM, Gary Adams wrote:
While running a block of nsk/jvmti/scenarios tests, I noticed an
occasional failure
for cm02t001 in windows debug platform. After enabling the nsk verbose
diagnostics and adding a few messages in the main test and the
debuggee
thread, it became clear that the missing contention was due to the
main thread
getting ahead of the debugee thread.
The call to letFinish() below let's the deuggee thread wake up from
it's wait
and proceed to the contention for the endingMonitor. If the main
thread
waits a little longer it should reach the debuggee thread
synchronized block.
I reopened an earlier bug that was closed as CNR.
Issue: https://bugs.openjdk.java.net/browse/JDK-8036026
diff --git
a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java
b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java
---
a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java
+++
b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java
@@ -82,7 +82,7 @@
thread.letFinish();
// pause to provoke contention
- Thread.sleep(100);
+ Thread.sleep(1000);
} catch (InterruptedException e) {
throw new Failure(e);
}
