Bug 252981

Created attachment 465195 [details] Plot of richards-wasm score vs number of worklist threads, --useBBQJIT=false --useOMGJIT=false Running the wasm parts of JS2 (wasm-cli.js) with useConcurrentJIT=true on an 80-core ARM64 box results in a performance slowdown. Specifically, with --useBBQJIT=false --useOMGJIT=false, the total score for wasm-cli.js hovers around 10 with useConcurrentJIT=true and between 13-14 for useConcurrentJIT=false. As far as I can tell, this is because of contention when claiming functions from the Wasm::LLintPlan in the Wasm::Worklist. I can easily bring it back to parity with the useConcurrentJIT=false case by changing the worklist code to spawn a single thread or by only notifying one of the threads for the compilation phase. The test most affected seems to be richards-wasm. Experimenting just with richards-wasm, I see performance start dropping off when the number of threads goes over 12 or so. This may not currently be a big problem on end user devices, but it does affect benchmarking and is probably going to become more of an issue in the future. I've experimented with simply batching the workload: have each worklist thread claim consecutive functions (up to functionBytes/batchSize, functionBytes being the sum of the function sizes in the module, batchSize being a tunable) and I can finally get a modest (~10%) speedup for the useConcurrentJIT=true case with a batchSize of 16KB (didn't put a lot of effort into tuning). This probably applies on other wasm tiers too, but I haven't verified that. I can submit a PR with the batchSize changes but the batch size would have to be tuned for each user of Wasm::Worklist (and probably for each arch too).