RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently

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

Post by Gary Adams
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);

Gary Adams

2018-10-04 11:11:41 UTC

Patch attached.

I think one reviewer is sufficient for a trivial patch.

Post by Chris Plummer
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

Post by Gary Adams
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);
}

Gary Adams

2018-10-04 11:39:08 UTC

Oops, wrong comment used in the patch.
Fresh patch attached.

Post by Gary Adams
Patch attached.
I think one reviewer is sufficient for a trivial patch.

Post by Chris Plummer
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

Post by Gary Adams
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);
}

Daniel D. Daugherty

2018-10-04 15:45:47 UTC

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

Post by Gary Adams
Oops, wrong comment used in the patch.
Fresh patch attached.

Post by Gary Adams
Patch attached.
I think one reviewer is sufficient for a trivial patch.

Post by Chris Plummer
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

Post by Gary Adams
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);
             }

Gary Adams

2018-10-04 16:04:25 UTC

We currently use time factor 4 or 10 to scale up the jtreg tests.
The change I proposed was already 10x100 = 1000.
Since this is just a thread scheduling issue to let the debuggee
run til it blocks, it should not require more time to get the
switch to take place.

If this was a process scheduling issue, then more complex
coordination might be worth considering.

Post by Daniel D. Daugherty
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

Post by Gary Adams
Oops, wrong comment used in the patch.
Fresh patch attached.

Post by Gary Adams
Patch attached.
I think one reviewer is sufficient for a trivial patch.

Post by Chris Plummer
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

Post by Gary Adams
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);
}

Daniel D. Daugherty

2018-10-04 16:13:00 UTC

Post by Gary Adams
We currently use time factor 4 or 10 to scale up the jtreg tests.
The change I proposed was already 10x100 = 1000.

Agreed that you are already bumping it up by 10X.

Post by Gary Adams
Since this is just a thread scheduling issue to let the debuggee
run til it blocks, it should not require more time to get the
switch to take place.

Are you really trying to say that system load doesn't affect
thread scheduling time?

Post by Gary Adams
If this was a process scheduling issue, then more complex
coordination might be worth considering.

System load doesn't just affect process scheduling. It also
affects thread scheduling. If all the cores are busy, then
running another thread or another process is impacted.

In any case, I wasn't clear in my suggestion.

- Thread.sleep(100);
+ Thread.sleep(100 * timeoutFactor);

assuming there is some easy way to get access to the -timeoutFactor
parameter.

Dan

Post by Gary Adams
Oops, wrong comment used in the patch.
Fresh patch attached.

Post by Gary Adams
Patch attached.
I think one reviewer is sufficient for a trivial patch.

Post by Chris Plummer
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

Post by Gary Adams
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);
             }

Gary Adams

2018-10-04 17:00:27 UTC

Post by Gary Adams
We currently use time factor 4 or 10 to scale up the jtreg tests.
The change I proposed was already 10x100 = 1000.

Agreed that you are already bumping it up by 10X.

Post by Gary Adams
Since this is just a thread scheduling issue to let the debuggee
run til it blocks, it should not require more time to get the
switch to take place.

Are you really trying to say that system load doesn't affect
thread scheduling time?

In this particular test, the main thread and the debuggee thread
are toggling back and forth around several monitors and
synchronized code blocks. Not sure the tests are written
for an arbitrarily high system load.

Post by Gary Adams
If this was a process scheduling issue, then more complex
coordination might be worth considering.

System load doesn't just affect process scheduling. It also
affects thread scheduling. If all the cores are busy, then
running another thread or another process is impacted.
In any case, I wasn't clear in my suggestion.
- Thread.sleep(100);
+ Thread.sleep(100 * timeoutFactor);
assuming there is some easy way to get access to the -timeoutFactor
parameter.

Currently, timeoutFactor has not been introduced to the vmTestbase/nsk
test suite.

Post by Gary Adams
Oops, wrong comment used in the patch.
Fresh patch attached.

Post by Gary Adams
Patch attached.
I think one reviewer is sufficient for a trivial patch.

Post by Chris Plummer
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

Post by Gary Adams
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);
}

Daniel D. Daugherty

2018-10-04 17:03:12 UTC

Post by Gary Adams
We currently use time factor 4 or 10 to scale up the jtreg tests.
The change I proposed was already 10x100 = 1000.

Agreed that you are already bumping it up by 10X.

Post by Gary Adams
Since this is just a thread scheduling issue to let the debuggee
run til it blocks, it should not require more time to get the
switch to take place.

Are you really trying to say that system load doesn't affect
thread scheduling time?

Post by Gary Adams
If this was a process scheduling issue, then more complex
coordination might be worth considering.

System load doesn't just affect process scheduling. It also
affects thread scheduling. If all the cores are busy, then
running another thread or another process is impacted.
In any case, I wasn't clear in my suggestion.
- Thread.sleep(100);
+ Thread.sleep(100 * timeoutFactor);
assuming there is some easy way to get access to the -timeoutFactor
parameter.

Currently, timeoutFactor has not been introduced to the vmTestbase/nsk
test suite.

Ummmm.... The -timeoutFactor parameter comes with JavaTest/JTREG
so it is already supported in the test harness that is uses to
run the vmTestbase/nsk test suite... What am I missing here?

Dan

Post by Gary Adams
Oops, wrong comment used in the patch.
Fresh patch attached.

Post by Gary Adams
Patch attached.
I think one reviewer is sufficient for a trivial patch.

Post by Chris Plummer
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

Post by Gary Adams
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);
             }

Gary Adams

2018-10-04 18:48:31 UTC

fyi - I think JDK-8201603 tc02t001 is suffering from the same issue.
A sleep(100) is used to provoke a contention with the debuggee thread.
If the debuggee is not scheduled quickly enough, the main thread proceeds
to release the contended object M and the test fails because not all the
contended
conditions were reported event.

Post by Gary Adams
We currently use time factor 4 or 10 to scale up the jtreg tests.
The change I proposed was already 10x100 = 1000.

Agreed that you are already bumping it up by 10X.

Post by Gary Adams
Since this is just a thread scheduling issue to let the debuggee
run til it blocks, it should not require more time to get the
switch to take place.

Are you really trying to say that system load doesn't affect
thread scheduling time?

Post by Gary Adams
If this was a process scheduling issue, then more complex
coordination might be worth considering.

System load doesn't just affect process scheduling. It also
affects thread scheduling. If all the cores are busy, then
running another thread or another process is impacted.
In any case, I wasn't clear in my suggestion.
- Thread.sleep(100);
+ Thread.sleep(100 * timeoutFactor);
assuming there is some easy way to get access to the -timeoutFactor
parameter.

Currently, timeoutFactor has not been introduced to the vmTestbase/nsk
test suite.

Ummmm.... The -timeoutFactor parameter comes with JavaTest/JTREG
so it is already supported in the test harness that is uses to
run the vmTestbase/nsk test suite... What am I missing here?
Dan

Post by Gary Adams
Oops, wrong comment used in the patch.
Fresh patch attached.

Post by Gary Adams
Patch attached.
I think one reviewer is sufficient for a trivial patch.

Post by Chris Plummer
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

Post by Gary Adams
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);
}

Daniel D. Daugherty

2018-10-04 19:06:11 UTC

Just FYI...

http://mail.openjdk.java.net/pipermail/jtreg-use/2013-September/000256.html

shows how to access the test timeout factor.

There are a few tests in the repo that show code examples:

$ grep -r test.timeout.factor hotspot/jtreg
hotspot/jtreg/runtime/appcds/TestCommon.java:
System.getProperty("test.timeout.factor", "1.0");
hotspot/jtreg/runtime/appcds/TestCommon.java:
cmd.add("-Dtest.timeout.factor=" + timeoutFactor);
hotspot/jtreg/runtime/appcds/test-classes/ParallelLoad.java:
Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));

Your choice on how you want to proceed.

Thumbs up from me either way.

Dan

Post by Gary Adams
fyi - I think JDK-8201603 tc02t001 is suffering from the same issue.
A sleep(100) is used to provoke a contention with the debuggee thread.
If the debuggee is not scheduled quickly enough, the main thread proceeds
to release the contended object M and the test fails because not all
the contended
conditions were reported event.

Post by Gary Adams
We currently use time factor 4 or 10 to scale up the jtreg tests.
The change I proposed was already 10x100 = 1000.

Agreed that you are already bumping it up by 10X.

Post by Gary Adams
Since this is just a thread scheduling issue to let the debuggee
run til it blocks, it should not require more time to get the
switch to take place.

Are you really trying to say that system load doesn't affect
thread scheduling time?

Post by Gary Adams
If this was a process scheduling issue, then more complex
coordination might be worth considering.

System load doesn't just affect process scheduling. It also
affects thread scheduling. If all the cores are busy, then
running another thread or another process is impacted.
In any case, I wasn't clear in my suggestion.
- Thread.sleep(100);
+ Thread.sleep(100 * timeoutFactor);
assuming there is some easy way to get access to the -timeoutFactor
parameter.

Currently, timeoutFactor has not been introduced to the vmTestbase/nsk
test suite.

Ummmm.... The -timeoutFactor parameter comes with JavaTest/JTREG
so it is already supported in the test harness that is uses to
run the vmTestbase/nsk test suite... What am I missing here?
Dan

Post by Gary Adams
Oops, wrong comment used in the patch.
Fresh patch attached.

Post by Gary Adams
Patch attached.
I think one reviewer is sufficient for a trivial patch.

Post by Chris Plummer
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

Post by Gary Adams
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);
             }

Gary Adams

2018-10-08 11:30:20 UTC

Patch attached. (Added Dan as a reviewer)
Chris if you can push this, I still need patches sponsored.

To add time factor support is a much bigger task
that should be done consistently across all the
vmTestbase/nsk suite.

Post by Daniel D. Daugherty
Just FYI...
http://mail.openjdk.java.net/pipermail/jtreg-use/2013-September/000256.html
shows how to access the test timeout factor.
$ grep -r test.timeout.factor hotspot/jtreg
System.getProperty("test.timeout.factor", "1.0");
cmd.add("-Dtest.timeout.factor=" + timeoutFactor);
Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));
Your choice on how you want to proceed.
Thumbs up from me either way.
Dan

Post by Gary Adams
We currently use time factor 4 or 10 to scale up the jtreg tests.
The change I proposed was already 10x100 = 1000.

Agreed that you are already bumping it up by 10X.

Post by Gary Adams
Since this is just a thread scheduling issue to let the debuggee
run til it blocks, it should not require more time to get the
switch to take place.

Are you really trying to say that system load doesn't affect
thread scheduling time?

Post by Gary Adams
If this was a process scheduling issue, then more complex
coordination might be worth considering.

System load doesn't just affect process scheduling. It also
affects thread scheduling. If all the cores are busy, then
running another thread or another process is impacted.
In any case, I wasn't clear in my suggestion.
- Thread.sleep(100);
+ Thread.sleep(100 * timeoutFactor);
assuming there is some easy way to get access to the
-timeoutFactor parameter.

Currently, timeoutFactor has not been introduced to the vmTestbase/nsk
test suite.

Ummmm.... The -timeoutFactor parameter comes with JavaTest/JTREG
so it is already supported in the test harness that is uses to
run the vmTestbase/nsk test suite... What am I missing here?
Dan