<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Jon,<br>
    &nbsp;&nbsp; I don't think it is as simple as designating a length of time<br>
    a test is allowed to run. In the scenario, I mentioned below <br>
    a test needed 5 seconds to perform it's main task and 1 second to <br>
    clean up. Internally both operations were manged with separate <br>
    timeouts.<br>
    <br>
    &nbsp; The jtreg harness allows for timefactor=2 to allow for 2*(5+1)<br>
    or 12 seconds to complete, but the test as written really needs<br>
    (2*5) + (2*1) seconds to run correctly. e.g. it has to allow for 2
    seconds<br>
    in the cleanup on the slower machine.<br>
    <br>
    &nbsp; If we can provide the (6 seconds * 2 timefactor) to the test it<br>
    could divide up the time between subtasks, but that may be a fairly
    <br>
    complicated computation over a large number of tests currently using<br>
    hard coded timeouts.<br>
    <br>
    Gary<br>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <pre style="white-space: pre-wrap">=======
With respect, my sense is that this is somewhat misdirected 
micromanagement.  It's not the time factor that the test should know, 
but the actual allotted time.   Given a certain period of time, a test 
could breakdown the allotted time into intervals for each step of its 
processing.

Would that work for what you have in mind?

-- Jon
</pre>
    On 11/16/11 8:08 AM, Gary Adams wrote:
    <blockquote cite="mid:4EC3B5CD.4020402@oracle.com" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      I'm investigating the current jdk tests with timeouts to see if we
      <br>
      can make them more reliable for slower machines. As a a first
      step,<br>
      I want to see if the jtreg command line arguments can be made <br>
      visible to the individual test.<br>
      <br>
      Second I want to explore the information about the target machine
      that<br>
      can help adjust time limits from the time sensitive tests.<br>
      <br>
      -------- Original Message --------
      <table class="moz-email-headers-table" border="0" cellpadding="0"
        cellspacing="0">
        <tbody>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
            </th>
            <td>Re: Passing time factor to tests run under jtreg</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
            <td>Tue, 15 Nov 2011 22:45:03 +0000</td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
            <td>Alan Bateman <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:Alan.Bateman@oracle.com">&lt;Alan.Bateman@oracle.com&gt;</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
            <td>gary Adams <a moz-do-not-send="true"
                class="moz-txt-link-rfc2396E"
                href="mailto:Gary.Adams@Oracle.COM">&lt;Gary.Adams@Oracle.COM&gt;</a></td>
          </tr>
          <tr>
            <th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
            <td><a moz-do-not-send="true"
                class="moz-txt-link-abbreviated"
                href="mailto:core-libs-dev@openjdk.java.net">core-libs-dev@openjdk.java.net</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <pre>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:
&gt;  I've been scanning a number of the slow machine test
&gt; bugs that are reported and wanted to check to see if
&gt; anyone has looked into time dependencies in the regression
&gt; tests previously. From what I've been able to learn so far
&gt; individual bugs can use the "timeout" parameter to indicate to
&gt; the test harness an expected time to run.
&gt;
&gt; The test harness has command line arguments where it can
&gt; filter out tests that take too long (timelimit) or can apply a 
&gt; multiplier to
&gt; to the timeout when conditions are known to slow down the process
&gt; (timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp
&gt;
&gt; I see that there are some wrappers that can be applied around running
&gt; a particular test to allow processing before main(). Could this mechanism
&gt; be exploited so the harness command line options could be made known
&gt; to the time dependent tests as command line arguments or as system
&gt; properties?
&gt;
&gt; My thought is the current timeout granularity is too large and only 
&gt; applies
&gt; to the full test execution. If a test knew that a timeoutFactor was to 
&gt; be applied,
&gt; it could internally adjust the time dependent delays appropriately. e.g.
&gt; not every sleep(), await(), join() with timeouts  would need the 
&gt; timeoutFactor
&gt; applied.
&gt;
&gt; Before any test could be updated the information would need to be 
&gt; available
&gt; from the test context.
&gt;
&gt; Any feedback/pointers appreciated!
&gt;
&gt;
&gt; See
&gt;  timeoutFactorArg
&gt;     jtreg/src/share/classes/com/sun/javatest/regtest/Main.java
&gt;  runOtherJVM()
&gt;     jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java
&gt;  maxTimeoutValue
&gt;     
&gt; jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java
&gt;
&gt;

</pre>
    </blockquote>
    <br>
  </body>
</html>