RFR: 8290211: jdk/internal/vm/Continuation/Fuzz.java failed with "AssertionError: Failed to compile int Fuzz.com_int(int, int) in 5000ms" [v2]

[Daniel D. Daugherty]

On Fri, 19 Aug 2022 19:48:24 GMT, Daniel D. Daugherty <dcubed at 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