RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently
Chris Plummer
chris.plummer at oracle.com
Wed Oct 3 20:49:05 UTC 2018
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);
> }
More information about the serviceability-dev
mailing list