On Wed, 13 Aug 2025 01:51:44 GMT, SendaoYan <s...@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: ... > > test/hotspot/jtreg/compiler/c2/TestStressRecompilation.java line 29: > >> 27: * @requires vm.debug >> 28: * @summary Test running with StressRecompilation enabled. >> 29: * @run main/othervm/timeout=480 -Xcomp -XX:+IgnoreUnrecognizedVMOptions >> -XX:+StressRecompilation > > I think the default value(120s) will be enough? On my machine this test use > 11.546 senonds to finish. > > >> grep "elapsed time" >> tmp/compiler/classUnloading/methodUnloading/TestOverloadCompileQueues.jtr -rn > 55:elapsed time (seconds): 0.581 > 66:elapsed time (seconds): 0.575 > 116:elapsed time (seconds): 3.088 > 162:elapsed time (seconds): 0.001 > 173:elapsed time (seconds): 11.546 I have only (to my knowledge) updated test cases that has timed out for me. We have some not very modern test machines that is slower. That in combination with a debug build, in combination with a timeout factor of 0.7 might have made the test time out. Unfortunately I no longer have the logs for this failure so I can not check if the machine was failing because it was low on memory etc. I still think it is reasonable to keep the old timeout of 480. I have no intuitive feeling for how expensive `-XX:+StressRecompilation` is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26749#discussion_r2273488236
