On Fri, 19 Aug 2022 19:48:24 GMT, Daniel D. Daugherty <dcu...@openjdk.org> wrote:
>> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG >> setting >> when waiting for a compilation to finish. >> >> This fix is being tested in my jdk-20+10 stress testing run. >> >> The usual Mach5 timeoutFactor is 4.0 with slower configurations using a >> timeoutFactor >> of 10.0. In my stress testing, I use release-bits: 4.0, fastdebug-bits: 6.0 >> and slowdebug-bits: 12.0. > > Daniel D. Daugherty has updated the pull request incrementally with one > additional commit since the last revision: > > Scale the original COMPILATION_TIMEOUT value of 5 seconds by timeoutFactor. Sorry for the delay in getting back to this PR. I've been focused on GateKeeping issues instead. This latest update: - Scale the original COMPILATION_TIMEOUT value of 5 seconds by timeoutFactor. makes the test happy on my linux-x64 stress runs. My macosx-aarch64 stress runs are still not happy, but I'm still gathering data on those runs. I haven't found a COMPILATION_TIMEOUT initial value that works every time yet. The values I've tried so far: - 1_000 - the original value in the PR - 5_000 - the original value in the test before I changed it - 10_000 - simple doubling - 20_000 - simple doubling again, testing this value now and thru the weekend I'm inclined to move ahead with the 5_000 value scaled by timeoutFactor. I think I need to spend some time to determine why macosx-aarch64 is so much slower than linux-x64 for this test. ------------- PR: https://git.openjdk.org/jdk/pull/9844
