DOI:10.1145/3282510 Bringing the Web Up to Speed with WebAssembly By Andreas Rossberg, Ben L. Titzer, Andreas Haas, Derek L. Schuff, Dan Gohman, Luke Wagner, Alon Zakai, J.F. Bastien, and Michael Holman Abstract Why are these goals important? Why are they hard? The maturation of the Web platform has given rise to sophis- Safe. Safety for mobile code is paramount on the Web, since ticated Web applications such as 3D visualization, audio code originates from untrusted sources. Protection for mobile and video software, and games. With that, efficiency and code has traditionally been achieved by providing a managed security of code on the Web has become more important language runtime such as the browser’s JavaScript Virtual than ever. WebAssembly is a portable low-level bytecode Machine (VM) or a language plugin. Managed languages that addresses these requirements by offering a compact enforce memory safety, preventing programs from compromis- representation, efficient validation and compilation, and ing user data or system state. However, managed language run- safe execution with low to no overhead. It has recently been times have traditionally not offered much for low-level code, made available in all major browsers. Rather than commit- such as C/C++ applications that do not use garbage collection. ting to a specific programming model, WebAssembly is an Fast. Low-level code like that emitted by a C/C++ compiler abstraction over modern hardware, making it independent is typically optimized ahead-of-time. Native machine code, of language, hardware, and platform and applicable far either written by hand or as the output of an optimizing com- beyond just the Web. WebAssembly is the first mainstream piler, can utilize the full performance of a machine. Managed language that has been designed with a formal semantics runtimes and sandboxing techniques have typically imposed from the start, finally utilizing formal methods that have a steep performance overhead on low-level code. matured in programming language research over the last Universal. There is a large and healthy diversity of pro- four decades. gramming paradigms, none of which should be privileged or penalized by a code format, beyond unavoidable hard- ware constraints. Most managed runtimes, however, have 1. INTRODUCTION been designed to support a particular language or program- The Web began as a simple hypertext document network ming paradigm well while imposing significant cost on but has now become the most ubiquitous application plat- others. form ever, accessible across a vast array of operating sys- Portable. The Web spans not only many device classes, tems and device types. By historical accident, JavaScript is but different machine architectures, operating systems, and the only natively supported programming language on the browsers. Code targeting the Web must be hardware- and Web. Because of its ubiquity, rapid performance improve- platform-independent to allow applications to run across all ments in modern implementations, and perhaps through browser and hardware types with the same deterministic sheer necessity, it has become a compilation target for behavior. Previous solutions for low-level code were tied to a many other languages. Yet JavaScript has inconsistent per- single architecture or have had other portability problems. formance and various other problems, especially as a com- Compact. Code that is transmitted over the network pilation target. should be small to reduce load times, save bandwidth, and WebAssembly (or “Wasm” for short) addresses the prob- improve overall responsiveness. Code on the Web is typically lem of safe, fast, portable low-level code on the Web. Previous transmitted as JavaScript source, which is far less compact attempts, from ActiveX to Native Client to asm.js, have fallen than a binary format, even when minified and compressed. short of properties that such a low-level code format should Binary code formats are not always optimized for size either. have: WebAssembly is the first solution for low-level code on the Web that delivers on all of the above design goals. It is • Safe, fast, and portable semantics: the result of an unprecedented collaboration across all – safe to execute – fast to execute a – language-, hardware-, and platform-independent WebAssembly engines are not assumed to spend time on sophisticated optimizations, because producers usually can take care of that more cheaply – deterministic and easy to reason about offline. Hence WebAssembly does not magically make code faster. But it – simple interoperability with the Web platform allows other languages to bypass the cost and complexity of JavaScript. • Safe and efficient representation: – maximally compact The original version of this paper was published in – easy to decode, validate and compile Proceedings of the 38th ACM SIGPLAN Conference on – easy to generate for producers Programming Language Design and Implementation – streamable and parallelizable (Barcelona, Spain, June 18–23, 2017), 185–200. DECEMBER 2018 | VOL. 61 | NO. 12 | COMMUNICATIONS OF THE ACM 107 research highlights major browser vendors and an online community group to module can only interact with its environment through its build a common solution for high-performance imports which are provided by a client, so that the client has applications.a full control over the capabilities given to a module. Both While the Web is the primary motivation for WebAssembly, these aspects are essential ingredients to the safety of its design—despite the name—carefully avoids any depen- WebAssembly. dencies on the Web. It is an open standard intended for Functions. The code in a module is organized into indi- embedding in a broad variety of environments, and other vidual functions, taking parameters and returnng results as such embeddings are already being developed. defined by its function type. Functions can call each other, To our knowledge, WebAssembly also is the first indus- including recursively, but are not first class and cannot be trial-strength language that has been designed with nested. The call stack for execution is not exposed, and thus a formal semantics from the start. It not only demonstrates cannot be directly accessed by a running WebAssembly pro- the “real world” feasibility of applying formal techniques, gram, even a buggy or malicious one. but also that they lead to a remarkably clean and simple Instructions. WebAssembly is conceptually based on a design. stack machine: code for a function consists of a sequence of instructions that manipulate values on an implicit operand 2. A TOUR OF THE LANGUAGE stack. However, thanks to the type system (Section 3.2), the Even though WebAssembly is a binary code format, we define layout of the operand stack can be statically determined at it as a programming language with syntax and structure. As any point in the code, so that implementations can compile we will see, that makes it easier to explain and understand the data flow between instructions directly without ever and moreover, allows us to apply well-established formal materializing the operand stack. The stack organization is techniques for defining its semantics and for reasoning merely a way to achieve a compact program representation, about it. Hence, Figure 1 presents WebAssembly in terms of as it has been shown to be smaller than a register machine. a grammar for its abstract syntax. Traps. Some instructions may produce a trap, which immediately aborts the current computation. Traps cannot 2.1. Basics (currently) be handled by WebAssembly code, but an embed- Let us start by introducing a few unsurprising concepts der will typically provide means to handle this condition, for before diving into less obvious ones in the following. example, by reifying them as JavaScript exceptions. Modules. A WebAssembly binary takes the form of a mod- Machine types. WebAssembly has only four basic value ule. It contains definitions forfunctions , globals, tables, and types t to compute with. These are integers and IEEE 754 memories.b Definitions may be exported or imported. floating point numbers, each with 32 or 64 bits, as available While a module corresponds to the static representation in common hardware. Most WebAssembly instructions pro- of a program, a module’s dynamic representation is an vide simple operators on these data types. The grammar in instance, complete with its mutable state. Instantiating a Figure 1 conveniently distinguishes categories such as unary module requires providing definitions for all imports, which and binary operators, tests, comparisons, and conversions. may be exports from previously created instances. Compu- Like hardware, WebAssembly makes no distinction between tations is initiated by invoking an exported function. signed and unsigned integer types. Instead, where it mat- Modules provide both encapsulation and sandboxing: ters, a sign extension suffix _u or _s to an instruction selects because a client can only access the exports of a module, either unsigned or two’s complement signed behavior. other internals are protected from tampering; dually, a Variables. Functions can declare mutable local variables, which essentially provides an infinite set of zero-initialized b WebAssembly’s text format closely resembles this syntax. For brevity we virtual registers. A module may also declare typed global vari- omit minor features regarding initialization of modules. ables that can be either mutable or immutable and require an explicit initializer. Importing globals