Closed Bug 1526219 Opened 7 months ago Closed 7 months ago

Reenable atomics tests on as many configurations as possible


(Core :: Javascript: WebAssembly, enhancement, P2)




Tracking Status
firefox67 --- fixed


(Reporter: lth, Assigned: lth)



(1 file)

The wasm atomics tests were prone to timeouts and hence were marked "slow", which is a euphemism for "never ever run them at all". This is bad; we need the test coverage. We should split the file, bailout early, disable tests on slow configurations, fix any deadlock issues, or otherwise rectify this so that the tests are run when at all possible.

Some reference numbers. jit_test does four runs by default. Running with -j1, I get about 6s / run, regardless of whether the shell is compiled with or without debugging or with or without optimization (because most of the time is spent in compiled wasm and it's not sensitive to those settings).

In bug 1480725 comment 11 I speculate that the poor performance is due to virtualization effects on the build / test servers, eg, one virtual core would not allow these spinning tests to advance fast enough to complete, as each thread needs to reach a preemption point before the next one can do any work.

If that is so, it may be worth trying to discover whether there are multiple (virtualized) cores available; really, multi-core is a prerequisite for the test case anyway, not just multi-thread.

The atomicity test cases require multiple cores so that multiple
workers can run concurrently; if enough cores are not available then
the tests will just take forever to execute because they'll be waiting
on preemption. (In practice, the tests will time out.)

So guard execution of the test on the availability of enough cores.

The guard may mean that the tests are not run on all test platforms,
but they should be run on developer systems and on platforms where we
run tests non-virtualized, eg, android hardware -- provided there are
enough cores. This is a real improvement over the current situation,
in which the tests are marked slow and thus never run at all.

Pushed by
Guard atomicity tests on a plausible core count. r=luke
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
You need to log in before you can comment on or make changes to this bug.