RFR: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 [v3]

[SendaoYan]

On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This changes the timeout factor from 4 to 1. Most of the changes add timeouts to individual test cases so that I am able to run them with a timeout factor of 0.7 (some margin to the checked in factor of one)
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the Java properties (I cannot use the library function everywhere as jtreg does not allow me to add @library notations to non test case files).
>> 
>> My approach has been to run all tests, and afterwards updating those that fail due to the timeout factor. The amount of updated test cases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed. In a few places, I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have ploughed through test cases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> After the review, I will update the copyrights.
>> 
>> I have run testing tier1-8. The last time with a timeout factor of 1 instead of 0.7.
>> 
>> I got 4 timing related faults:
>> 1) runtime/Thread/TestThreadDumpMonitorContention.java
>>    This is probably: https://bugs.openjdk.org/browse/JDK-8361370
>> 2) sun/tools/jhsdb/BasicLauncherTest.java
>>    I am unsure about this one, it has not failed on my runs before, even with a timeout factor of 0.7, maybe I was unlucky.
>> 3) gc/stress/TestReclaimStringsLeaksMemory.java
>>    I updated this to 480 seconds, I finish this fairly fast (~14s) on my not very fast computer, but the Macs that fail are old x86-based ones.
>> 4) sun/security/ssl/X509KeyManager/CertChecking.java
>>    This is a new test that I got on last rebase. I have added a timeout of 480 to it.
>> 
>> In addition to these four tests, I have another one "java/lang/ThreadLocal/MemoryLeak.java" that earlier failed with a timeout factor of 0.7 but did not fail in the last run. I will *not* update that test case, because the extra time spent is strange and should be looked at. I have created JDK-8352074 on that test case, and I will probably create another bug describing the timeout I got.
>> 
>> From the review of the cancelled "8356171: ...
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra timeout for: jdk/internal/vm/Continuation/BasicExt.java#COMP_WINDOW_LENGTH_{1-3}-GC_AFTER_YIELD

make/RunTests.gmk line 940:

> 938:   JTREG_AUTO_PROBLEM_LISTS :=
> 939:   # Please reach consensus before changing this. It was not easy changing it to a `1`.
> 940:   JTREG_AUTO_TIMEOUT_FACTOR := 1

Since the default value of JTREG_AUTO_TIMEOUT_FACTOR set to 1 by default, then the value of [JTREG_AUTO_TIMEOUT_FACTOR](https://github.com/lkorinth/jdk/blob/dbe42964371a38b2c6cd9e842c5b28ca4ac15506/make/RunTests.gmk#L944) when run with -Xcomp should be change from 10 to 2.5()

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2279056261