Closed Bug 1630926 Opened 4 years ago Closed 4 years ago

Multi-value tests time out on arm64 emulator

Categories

(Core :: JavaScript: WebAssembly, defect, P1)

ARM64
Linux
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: lth, Assigned: wingo)

References

Details

Configure thusly (my build dir is a subdir of js/src):

../configure --enable-debug --disable-optimize --without-intl-api --enable-simulator=arm64

Build as usual, then:

../jit-test/jit_test.py -f dist/bin/js wasm/multi-value

On current mozilla-central (524560:48cefa8cc058) without any patches applied, the test multi-value/call-ref times out.

Since this is a noopt debug build and a slow simulator it could just be an actual timeout, but the loop bound in that test is not that large, so filing this before investigating further.

(Yesterday, on an older m-c, ion-inlining also timed out, but it does not do that with this version of m-c.)

I have no idea why we're not seeing this failure on threeherder, as the arm64-sim tests are running there on a linux64-debug configuration.

Cutting the loop bound by a factor of 100 makes a test run of this case only finish in 3.7s so it's probably just a case of the test case being broken, but it would be good to look into it and then also ensure that the test finishes in a reasonable amount of time.

Indeed with that hack, the run of all the multi-value tests takes 137s on my system in this configuration, suggesting there are some tests here that take a very long time. Would be good to diagnose, maybe discuss if we can make them faster.

I took a look and I think the slowness is for four reasons that compound each other:

  1. We don't get JIT entry or exit for wasm
  2. JS and Wasm code is being simulated. I checked and the JS is Ion-compiled, fwiw.
  3. The simulator is being run without optimizations
  4. The test has a not-small iteration count because it was inspired by CGC bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=1609889#c9

Some data, all run with --no-threads fwiw:

x64 release mode: 150ms
x64 debug mode, with optimizations: 1140 ms
x64 debug mode, no optimizations: 13416 ms
aarch64 simulator, release mode: 6430 ms
aarch64 simulator, debug mode, with optimizations: 51550 ms
aarch64 simulator, debug mode, no optimizations: 458006 ms

So to conclude -- for this test, running the simulator is about a 40x slowdown, running debug mode is around 10x, and disabling optimizations is another 10x or so. What should we do here? :)

OK, I guess I can live with it, as I am currently living with a number of timeouts for this testing combination. I think I'm almost the only one using it - everyone else is using debug+optimize.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.