> 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: Increase timeout for test cases as
> preparation for change of...
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
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/26749/files
- new: https://git.openjdk.org/jdk/pull/26749/files/dbe42964..8fa40e7d
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=26749&range=01-02
Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
Patch: https://git.openjdk.org/jdk/pull/26749.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/26749/head:pull/26749
PR: https://git.openjdk.org/jdk/pull/26749
