On Thu, 18 Jan 2024 13:14:19 GMT, Daniel D. Daugherty <dcu...@openjdk.org> wrote:
> It is only with extremely high > stress levels that we see these slowdebug timeouts. I would have considered this as a reason to be using timeoutfactor and not increase the timeouts. Although I don't think what to use as the default timeout for any given test has ever been formalized, certainly the idea is that the test should be expected to pass with the provided timeout (default or specified) on a machine with some given performance expectations (num cores, performance of each core, machine load), and with a jdk build with some given performance expectations (product, fastdebug, slowdebug, -Xcomp, -Xint, etc). Anytime those expectations are not met, timeoutfactor should be used. Your changes imply that the timeout should be good enough for a slowdebug build on a machine with a heavy load. I'm not so sure that makes sense when we have timeoutfactor to deal with such situations. In other words, set one test parameter that will cover all your test runs instead of having to update a large number of tests to make the tests pass on your system. If that is not what timeou tfactor is for, then I don't see why it even exists. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17478#issuecomment-1898776484
