Repairing and Mechanising the JavaScript Relaxed Memory Model Conrad Watt Christopher Pulte Anton Podkopaev University of Cambridge University of Cambridge HSE / MPI-SWS UK UK Russia / Germany [email protected] [email protected] [email protected] Guillaume Barbier Stephen Dolan Shaked Flur ENS Rennes University of Cambridge University of Cambridge∗ France UK UK [email protected] [email protected] [email protected] Jean Pichon-Pharabod Shu-yu Guo University of Cambridge Bloomberg LP∗ UK USA [email protected] [email protected] Abstract CCS Concepts: • Computing methodologies Concur- ! Modern JavaScript includes the SharedArrayBuffer feature, rent programming languages; • General and reference Verification. which provides access to true shared memory concurrency. ! SharedArrayBuffers are simple linear buffers of bytes, and Keywords: the JavaScript specification defines an axiomatic relaxed Alloy, ARMv8, Coq, weak memory, Web worker memory model to describe their behaviour. While this model is heavily based on the C/C++11 model, it diverges in some key areas. JavaScript chooses to give a well-defined semantics to data-races, unlike the “undefined behaviour” of C/C++11. Moreover, the JavaScript model is mixed-size. This means 1 Introduction that its accesses are not to discrete locations, but to (possibly JavaScript is widely publicised as a “single-threaded lan- overlapping) ranges of bytes. guage” [39], with asynchronously dispatched events pro- We show that the model, in violation of the design in- cessed by a single event loop. JavaScript (JS) allows the use tention, does not support a compilation scheme to ARMv8 of threads, called Web Workers, for parallel computation, but which is used in practice. We propose a correction, which until recently these were not allowed to share access to mu- also incorporates a previously proposed fix for a failure of table state, and inter-thread communication was restricted the model to provide Sequential Consistency of Data-Race- purely to message-passing [11]. However, a new feature of Free programs (SC-DRF), an important correctness condi- JavaScript, SharedArrayBuffer, allows true concurrent access tion. We use model checking, in Alloy, to generate small to a low-level shared resource [18]. SharedArrayBuffers are counter-examples for these deficiencies, and investigate our simple linear mutable byte buffers, and, unlike other Java- correction. To accomplish this, we also develop a mixed-size arXiv:2005.10554v2 [cs.PL] 22 May 2020 Script objects, references to the same SharedArrayBuffer extension to the existing ARMv8 axiomatic model. may be held by multiple Web Workers simultaneously. Guided by our Alloy experimentation, we mechanise (in SharedArrayBuffers were originally specified and imple- Coq) the JavaScript model (corrected and uncorrected), our mented by all major browsers in 2017, but were disabled ARMv8 model, and, for the corrected JavaScript model, a shortly after due to concerns about Spectre and Meltdown. “model-internal” SC-DRF proof and a compilation scheme Now that mitigations have been developed, the feature has correctness proof to ARMv8. In addition, we investigate a been re-introduced into the web ecosystem [15]. non-mixed-size subset of the corrected JavaScript model, SharedArrayBuffers have several important uses. They are and give proofs of compilation correctness for this subset the only mechanism in JavaScript for true shared-memory to x86-TSO, Power, RISC-V, ARMv7, and (again) ARMv8, via concurrency. C++ is often compiled to asm.js [28], a fast the Intermediate Memory Model (IMM). JavaScript subset, for use on the web, and concurrent C++ As a result of our work, the JavaScript standards body (ECMA TC39) will include fixes for both issues in an upcom- ing edition of the specification. ∗ At the time the work was done. Watt, Pulte, Podkopaev, Barbier, Dolan, Flur, Pichon-Pharabod, andGuo objects must be allocated on SharedArrayBuffers in the com- 1.1 Mixed-Size piled program. SharedArrayBuffers also provide the mecha- In some respects, the JavaScript relaxed memory model is nism by which JavaScript may interoperate with concurrent similar to that of C/C++ [9], sharing an axiomatic nature and WebAssembly programs [27]. several core definitions and relations. However, the mixed- The JavaScript specification must define the concurrent size nature of the JavaScript model is a substantial compli- behaviours that are possible when the same SharedArray- cation in its verification. Unlike what prior work typically Buffer is accessed concurrently by multiple Web Workers; assumes, memory accesses can be of different sizes (byte- this is done through a relaxed memory model. The relaxed widths); hence, two accesses may overlap without having the memory model of JavaScript was designed to conform to an exact same “footprint”, adding another dimension of com- ambitious set of requirements [20]: plexity to the model, and limiting our ability to make use of prior work in which this is assumed not to occur. Mixed-size accesses. JavaScript’s concurrency is mixed- To the best of our knowledge, only a single previous work, size, in the sense of Flur et al.[22]: accesses are not to individ- Flur et al.[22], deals with the formal verification of compila- ual, discrete locations, but instead to ranges of byte locations, tion of a mixed-size relaxed memory model. Flur et al. con- which may overlap with each other. centrate mainly on architecture-level mixed-size behaviours, proposing operational mixed-size models for the ARMv8 and Mixed atomic and non-atomic accesses. JavaScript has POWER architectures. Their work describes an extension no concept of an “atomic location”, so atomic and non-atomic to an existing formalisation of C/C++11, adding mixed-size accesses may be arbitrarily combined on the same location. non-atomics, and gives a sketch hand-proof that the resulting JavaScript has only one type of atomic access, SeqCst, while model can be correctly compiled to POWER, acknowledging C/C++11 also has so-called “low-level atomics” such as re- that fuller verification is an open problem. Even this mixed- lease/acquire. size C/C++11 model only allows mixed-size non-atomics, on which a data race leads to undefined behaviour. The Java- No undefined behaviour. The JavaScript language does Script memory model, in contrast, must give well-defined not have a concept of undefined behaviour, so all programs behaviour even in the case of data races between partially- must have behaviour defined by the standard. This remains overlapping accesses. true even in the presence of data-races, although the defined Two other papers deal with mixed-size models. Watt et al. behaviour is then extremely weak. [52] describe a memory model for WebAssembly that is closely related to the JavaScript memory model. The au- C++-compatible compilation. JavaScript atomic accesses thors do not attempt a proof of correctness of compilation, are to use the same compilation scheme as C++ SC-atomic again declaring it as an open problem. They report on a accesses [20, p. 17]. deficiency in the JavaScript memory model which wein- vestigate further as part of this work. Finally, the EMME SC-DRF. Programs that are free of data races must have tool [37] represents an earlier investigation of JavaScript’s sequentially consistent behaviour [20, p. 8]. memory model using the Alloy model checker [29]. This tool is engineered primarily as a test oracle, and the work Whatever JavaScript’s general reputation, it should be does not attempt compilation scheme verification. We also emphasised that its current specification is particularly rig- make use of Alloy during this work, but primarily for com- orous. Because of its ubiquity on the Web and the large pilation scheme investigation, in the style of Memalloy [53]. number of language implementers, great care is taken to We discuss differences in our approaches in§8. ensure that its features are precisely defined.1 In particular, its relaxed memory model is defined using an unambiguous, semi-formal pseudocode, which takes inspiration from pre- 1.2 Our Contributions vious formalisations of the memory models of C/C++11 [9] ARMv8 compilation scheme failure. We have discov- and Java [34]. In addition, SharedArrayBuffers have been ered that, on ARMv8, compiling JavaScript atomics by fol- carefully designed to participate as little as possible in Java- lowing the standard compilation scheme for C++ SC atomics Script’s complicated object inheritance model, effectively allows behaviours which violate the guarantees of the Java- allowing us to reason about them in isolation. Script memory model. This compilation scheme is already implemented in Google’s V8 JavaScript engine [13], and we are able to observe the violating behaviour experimentally through Web browsers on real hardware. After consultation 1 JavaScript’s least intuitive behaviours arise not out of failures of its current specification process, but out of a requirement to be backwards-compatible with implementers and ECMA TC39, the JavaScript stan- with earlier versions of the language. Often, this means specifying a strange dards body, we concluded that the JavaScript memory model behaviour for legacy reasons. should be weakened in order to support this scheme (§3.1). Repairing and Mechanising the JavaScript Relaxed Memory Model Fixing the JS specification. The JavaScript model also 1.3 Non-contributions fails to guarantee Sequential Consistency for Data-Race-Free C/C++11-style “out-of-thin-air” executions [7] are admitted programs (SC-DRF), a crucial correctness condition [2, 12, 23, by the JavaScript model for certain programs with racing 31]. This was discovered in previous work [52], which pro- non-atomics [52]. We acknowledge this is a deficiency of posed a strengthening of the model to restore SC-DRF, but the model, but we do not attempt to solve this long-standing did not verify that the strengthened condition is supported problem here; proposed solutions for C/C++11 involve either by existing compilation schemes.