WebAssembly is gaining more and more popularity, finding applications beyond the Web browser for which it was initially designed. However, its performance, which developers intended to be comparable with native, has not been extensively studied to identify overheads and pinpoint their causes. This paper identifies that WebAssembly's boundschecked memory access safety mechanism may introduce up to a 650% overhead, and requires further tuning. Based on that, we extend four popular WebAssembly runtimes with modern bounds checking mechanisms and compare the performance of each with native compiled code. The runtimes are evaluated on three different instruction set architectures: x86-64, Armv8, and RISC-V RV64GC. We show that, for simple numerical kernels from PolyBench/C, there are no significant differences in the bounds checking performance overheads across different instruction set architectures. With the default bounds checking mechanism, performance-oriented runtimes are able to achieve execution times within 20% of native on x86-64 platforms, within 35% on Armv8 platforms, and within 17% on RISC-V. We also show that, when scaling the tested runtimes to multiple threads, the default bounds checking approach taken by WAVM, Wasmtime, and V8 of using the mprotect syscall to resize memory can cause excessive locking in the Linux kernel. Such scaling might be used to quickly start up serverless instances for a single function without the overhead of spawning new processes. We present an alternative userfaultfd-based solution to mitigate this issue. We share our results, tools, and scripts under an open source license for other researchers to replicate and use to monitor the progress that WebAssembly runtimes make as they evolve.
