Gary - this might be something to bring up on the jtreg-use list.
Ideally the tests wouldn't have any hardcoded timeouts but sometimes
there isn't any other choice.
-Alan
On 15/11/2011 20:14, Gary Adams wrote:
I've been scanning a number of the slow machine test
bugs that are reported and wanted to check to see if
anyone has looked into time dependencies in the regression
tests previously. From what I've been able to learn so far
individual bugs can use the "timeout" parameter to indicate to
the test harness an expected time to run.
The test harness has command line arguments where it can
filter out tests that take too long (timelimit) or can apply a
multiplier to
to the timeout when conditions are known to slow down the process
(timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp
I see that there are some wrappers that can be applied around running
a particular test to allow processing before main(). Could this mechanism
be exploited so the harness command line options could be made known
to the time dependent tests as command line arguments or as system
properties?
My thought is the current timeout granularity is too large and only
applies
to the full test execution. If a test knew that a timeoutFactor was to
be applied,
it could internally adjust the time dependent delays appropriately. e.g.
not every sleep(), await(), join() with timeouts would need the
timeoutFactor
applied.
Before any test could be updated the information would need to be
available
from the test context.
Any feedback/pointers appreciated!
See
timeoutFactorArg
jtreg/src/share/classes/com/sun/javatest/regtest/Main.java
runOtherJVM()
jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java
maxTimeoutValue
jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java
