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

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

jdk/internal/vm/Continuation/Fuzz.java* passed 12 times (2 sub-tests x 6 
configs)
in two different Mach5 Tier1 job sets.

-

PR: https://git.openjdk.org/jdk/pull/9844


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

2022-08-19 Thread Jie Fu
On Fri, 19 Aug 2022 19:48:24 GMT, Daniel D. Daugherty  
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.

LGTM

Thanks for the update.

-

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9844


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

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


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

2022-08-19 Thread Daniel D . Daugherty
> 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.

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9844/files
  - new: https://git.openjdk.org/jdk/pull/9844/files/bd9be934..cd61c316

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=9844=01
 - incr: https://webrevs.openjdk.org/?repo=jdk=9844=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9844.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9844/head:pull/9844

PR: https://git.openjdk.org/jdk/pull/9844