Passing time factor to tests run under jtreg

Alan Bateman Alan.Bateman at oracle.com
Tue Nov 15 22:45:03 UTC 2011


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
>
>




More information about the core-libs-dev mailing list