JDK-8260555 : Change the default TIMEOUT_FACTOR from 4 to 1
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: test
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-01-27
  • Updated: 2025-10-29
  • Resolved: 2025-09-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26 b14Fixed
Related Reports
Causes :  
JDK-8367695 - tools/javac/completionDeps/DepsAndAnno.java timed out and PASSed
Causes :  
JDK-8369491 - Temporarily revert default TIMEOUT_FACTOR back to 4
Causes :  
JDK-8366950 - Test com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed
Causes :  
JDK-8368001 - java/text/Format/NumberFormat/NumberRoundTrip.java timed out
Causes :  
JDK-8367135 - Test compiler/loopstripmining/CheckLoopStripMining.java needs internal timeouts adjusted
Causes :  
JDK-8366692 - Several gc/shenandoah tests timed out
Causes :  
JDK-8366938 - Test runtime/handshake/HandshakeTimeoutTest.java crashed
Causes :  
JDK-8368098 - (aio) java/nio/channels/Channels/AsyncCloseStreams.java fails in junit timeout
Duplicate :  
JDK-8356171 - Increase timeout for testcases as preparation for change of default timeout factor
Relates :  
JDK-8367278 - Test compiler/startup/StartupOutput.java timed out after completion on Windows
Relates :  
JDK-8366704 - Bump timeout on TestInheritFD
Relates :  
JDK-8367318 - Test vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java timed out after passing
Relates :  
JDK-8367449 - Test runtime/cds/CDSMapTest.java timed out but passed
Relates :  
JDK-8367610 - Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java timed out on Windows
Relates :  
JDK-8368793 - java/lang/StringBuilder/RacingSBThreads.java timed out in Xcomp subtest
Relates :  
JDK-8367041 - Test tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java timed out
Relates :  
JDK-8367042 - Test jdk/jfr/jmx/streaming/TestRemoteDump.java timed out
Relates :  
JDK-8367043 - Test tools/javac/launcher/ModuleSourceLauncherTests.java timed out after completion
Relates :  
JDK-8368824 - Multiple httpclient tests pass and then time out on Windows
Relates :  
JDK-8366803 - Bump timeout on sun/tools/jhsdb/BasicLauncherTest.java
Relates :  
JDK-8366941 - Excessive logging in serviceability tests causes timeout
Relates :  
JDK-8367365 - java/math/BigInteger/BigIntegerTest.java failed in jtreg timeout
Relates :  
JDK-8367899 - compiler/c2/gvn/TestBitCompressValueTransform.java intermittent timed out
Relates :  
JDK-8368630 - java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout
Relates :  
JDK-8368866 - compiler/codecache/stress/UnexpectedDeoptimizationTest.java intermittent timed out
Relates :  
JDK-8367615 - JDI tests are timing out and passing
Relates :  
JDK-8367723 - Test jdk/jfr/jmx/streaming/TestMaxSize.java passed and timed out
Relates :  
JDK-8368344 - tools/javac/file/FSInfoTest.java completed and then timed out
Relates :  
JDK-8366776 - Timeout on ExpSwitchNestingTest.java
Relates :  
JDK-8367280 - Two java/nio/channels/Channels/TransferTo tests timed out during compilation
Relates :  
JDK-8367281 - Test serviceability/sa/TestDebugInfoDecode.java timed out
Relates :  
JDK-8366666 - Bump timeout on StressAsyncUL
Relates :  
JDK-8367279 - Test tools/javac/tree/TreePosTest.java timed out
Description
Today the default TIMEOUT_FACTOR passed to jtreg is 4. Consider changing it to 1, to make it's usage a bit more easy to understand. (Note that this property accepts a float, so one can set TIMEOUT_FACTOR=0.25, if needed)

This will require adaptation of the different code that use this property.

The ones I know of:
1) It's usage as a timeout for a test run. This default value will have to be bumped by x4.

2) It's usage to scale IO waits - It's not apparent to me that the existing usages actually expect the x4. If we want to retain it, we could probably scale the few existing usages.

3) It's usage to scale vmTestbase -stressTime. Need to change the default value, and update the tests that sets this explicitly. (Note, I'm not convinced that this scaling is good, but it's what our current tests do)

[This JBS entry comes after a lengthy discussion between me and Igor about TIMEOUT_FACTOR and how it's used]
Comments
Changeset: 55e7af05 Branch: master Author: Leo Korinth <lkorinth@openjdk.org> Date: 2025-09-02 07:27:12 +0000 URL: https://git.openjdk.org/jdk/commit/55e7af0560335ef69af072cee60956cf8e6d00a1
02-09-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26749 Date: 2025-08-12 17:01:41 +0000
12-08-2025
[~msheppar] I think this PR gives some insight into what areas are going to change: https://github.com/openjdk/jdk/pull/25122
09-05-2025
[~stefank] thanks for that .... yes, I have seen Leo's PR in the open review ... cheers [~dholmes] thanks .. I have seen the -Xcomp timeout factor adjustment (in ./open/make/RunTests.gmk), and some Graal job definitions adjust the timeout factor, but nothing else as such I was going to ask why not adjust the hotspot timeout factor via job definitions and leave the implicit default as is ? There will be (potentially) over 1300 tests affected by the removal of the implicit timeout factor would it make sense to have jtreg "enhanced" to support the setting of timeout and timeout factor from TEST.ROOT and TEST.properties, such that localised setting can be specified ?
09-05-2025
Is it the case that some tests in the hotspot use a timeout factor of 10 ?
08-05-2025
Is this proposal to adjust the TIMEOUT factor in the hotspot component only and leave all other component areas alone ?
08-05-2025
I think this is hard for /everyone/ to understand. For example, I guess the timeout factor for the interpreter has sometime been 10x the "normal". Not 2,5x as it is now. I believe the current situation is a bad patchwork where people applies a bit more timeout factor when stuff times out, and for a person writing a test it not even /possible/ to know what timeout factor is applied as the timeout factor can also be overridden on the command line (and is). When JTREG_TIMEOUT_FACTOR is applied with a value below 4, do you think that is done on purpose to increase the timeout or to decrease the timeout? I think it is thought to increase the timeout, even though the effect is the opposite (if I understand the makefiles correctly!!!). I also believe the timeout factor /should/ be used to signal that we are running on a slow machine, or that we are using an interpreter, or we are using some setting that makes execution slower (some debug setting for example) and not as a sloppy way to tell test suits not to time out. It would also be good if those could be factored onto each other, that is, running the interpreter with slowdebug on slow hardware would factor all timeout factors. I think removing a default timeout factor of 4 is the /first step/ to create a model that is simpler and understandable. Much more could of course be done.
20-11-2024
From my POV it is more intuitive if TIMEOUT_FACTOR where 1 instead of 4. In fact, I was fooled by this a couple of days ago when I set the TIMEOUT_FACTOR to 10 and anticipated it to 10-fold the timeout value. And I even know about the weirdness of TIMEOUT_FACTOR and how it used to influence the stressTime etc., and still messed up because of it. :)
14-11-2024
If you are debugging then you can set whatever timeout factor you need. Changing defaults affects the CI. We don't have machine-level granularity for managing this so you can't just set the timeout based on specific machine characteristics - if a macosx-x64 job is submitted to mach5 it will run on whatever range of macosx-x64 machines that we have: fast ones and slow ones. I'm still unclear exactly what you are proposing to change: jtreg? task-definitions? tests themselves? All of the above? [~lmesnik] what is your view on this?
14-11-2024
If for no other reason it is nice to only wait 2 minutes instead of 8 minutes when debugging time outs. But more importantly, it is hard to understand the current behaviour. If we have slow machines, only those should be run with another timeout factor, not all machines. If that was not the case, we should remove the specific timeout factor for tests using the interpreter as well... My current idea is that I will run tests with a timeout factor of 0.5 to fix slow test cases, after that all test cases ought to work using 1x factor. Today, the interpreter has 2.5x more time to complete an action then the default, I think 10x is more reasonable.
13-11-2024
I don't really understand the need for this change, nor exactly what is proposed. The value 4 is based on the actual timeout in minutes that it will cause jtreg to use, which in turn has been established as a good default for getting a long enough default timeout to cover the range of hardware and systems we have, without being so long as to consume excessive resources when timeouts do occur. When jtreg is run locally the default timeout factor is just 1 as developers don't need to adjust to support slow machines in general. If we instead set TIMEOUT_FACTOR=1 (or don't set it at all) that implies jtreg needs to be modified to change its internal default timeout by 4x to keep things the same. Is this just a documentation issue?
15-10-2024