Allocation Folding Based on Dominance Daniel Clifford Hannes Payer Michael Starzinger Ben L. Titzer Google fdanno,hpayer,mstarzinger,[email protected] Abstract of automatic memory management is of principal importance in Memory management system performance is of increasing impor- best utilizing computing resources across the entire spectrum. tance in today’s managed languages. Two lingering sources of over- Automatic memory management systems that rely on garbage head are the direct costs of memory allocations and write barriers. collection introduce some overhead in the application’s main exe- This paper introduces allocation folding, an optimization technique cution path. While some garbage collection work can be made in- where the virtual machine automatically folds multiple memory al- cremental, parallel, or even concurrent, the actual cost of executing location operations in optimized code together into a single, larger allocation operations and write barriers still remains. This is even allocation group. An allocation group comprises multiple objects more apparent in collectors that target low pause time and require and requires just a single bounds check in a bump-pointer style allo- heavier write barriers. cation, rather than a check for each individual object. More impor- This paper targets two of the most direct costs of garbage col- tantly, all objects allocated in a single allocation group are guaran- lection overhead on the application: the cost of allocation bounds teed to be contiguous after allocation and thus exist in the same gen- checks and write barriers executed inline in application code. Our eration, which makes it possible to statically remove write barriers optimization technique, allocation folding, automatically groups for reference stores involving objects in the same allocation group. multiple object allocations from multiple allocation sites in an op- Unlike object inlining, object fusing, and object colocation, alloca- timized function into a single, larger allocation group. The alloca- tion folding requires no special connectivity or ownership relation tion of an allocation group requires just a single bounds check in a between the objects in an allocation group. We present our analysis bump-pointer style allocator, rather than one check per object. Even algorithm to determine when it is safe to fold allocations together more importantly, our flow-sensitive compiler analysis that elimi- and discuss our implementation in V8, an open-source, production nates write barriers is vastly improved by allocation folding since JavaScript virtual machine. We present performance results for the a larger region of the optimized code can be proven not to require Octane and Kraken benchmark suites and show that allocation fold- write barriers. ing is a strong performance improvement, even in the presence of Allocation folding relies on just one dynamic invariant: some heap fragmentation. Additionally, we use four hand-selected Invariant 1. Between two allocations A1 and A2, if no other benchmarks JPEGEncoder, NBody, Soft3D, and Textwriter where operation that can move the object allocated at A1 occurs, then allocation folding has a large impact. space for the object allocated at A2 could have been allocated at Categories and Subject Descriptors D3.4 [Programming Lan- A1 and then initialized at A2, without ever having been observable guages]: Processors compilers, memory management (garbage to the garbage collector. collection), optimization Our optimization exploits this invariant to group multiple al- General Terms Algorithms, Languages, Experimentation, Per- locations in an optimized function into a single, larger allocation. formance, Measurement Individual objects can then be carved out of this larger region, with- out the garbage collector ever observing an intermediate state. Keywords Dynamic Optimization, Garbage Collection, Memory Allocation folding can be considered an optimization local to an Managment, Write barriers, JavaScript optimized function. Unlike object inlining [5], object fusing [21], or object colocation [11], the objects that are put into an alloca- 1. Introduction tion group need not have any specific ownership or connectivity Applications that rely on automatic memory management are now relationship. In fact, once the objects in a group are allocated and everywhere, from traditional consumer desktop applications to initialized, the garbage collector may reclaim, move, or promote large scale data analysis, high-performance web servers, financial them independently of each other. No static analysis is required, trading platforms, to ever-more demanding websites, and even bil- and the flow-sensitive analysis is local to an optimized function. lions of mobile phones and embedded devices. Reducing the costs Our technique ensures that allocation folding requires no special support from the garbage collector or the deoptimizer and does not interfere with other compiler optimizations. We implemented allo- cation folding in V8 [8], a high-performance open source virtual Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed machine for JavaScript. Our implementation of allocation folding for profit or commercial advantage and that copies bear this notice and the full citation is part of the production V8 code base and is enabled by default on the first page. Copyrights for components of this work owned by others than ACM since Chrome M30. must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, The rest of this paper is structured as follows. Section 2 de- to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. scribes the parts of the V8 JavaScript engine relevant to allocation ISMM ’14, June 12, 2014, Edinburgh, UK. folding, which includes the flow-sensitive analysis required for al- Copyright c 2014 ACM 978-1-4503-2921-7/14/06. $15.00. location folding and relevant details about the garbage collector and http://dx.doi.org/10.1145/2602988.2602994 write barriers. Section 3 describes the allocation folding algorithm and shows how allocation folding vastly widens the scope of write Instruction Dep Chg barrier elimination. Section 4 presents experimental results for al- In = PARAMETER[K] location folding across a range of benchmarks which include the In = CONSTANT[K] Octane [7] and Kraken [13] suites. Section 5 discusses related work In = ARITH(I; I) followed by a conclusion in Section 6. In = LOAD[field](object) Ψ In = STORE[field](object; value) Ψ I = ALLOC[space](size) Λ Λ 2. The V8 Engine n In = INNER[offset; size](alloc) V8 [8] is an industrial-strength compile-only JavaScript virtual ma- In = CALL(I:::) * * chine consisting of a quick, one-pass compiler that generates ma- In = PHI(I:::) chine code that simulates an expression stack and a more aggres- sive optimizing compiler based on a static single assignment (SSA) Table 1: Simplified Crankshaft IR Instructions. intermediate representation (IR) called Crankshaft, which is trig- gered when a function becomes hot. V8 uses runtime type pro- filing and hidden classes [9] to create efficient representations for JavaScript objects. Crankshaft relies on type feedback gathered at Every definition must dominate its uses, except for the inputs to runtime to perform aggressive speculative optimizations that tar- PHI instructions. get efficient property access, inlining of hot methods, and reduc- Table 1 shows a simplified set of Crankshaft instructions that ing arithmetic to primitives. Dynamic checks inserted into opti- will be used throughout this paper. Statically known parts of an mized code detect when speculation no longer holds, invalidat- instruction, such as the field involved in a LOAD or STORE, or the ing the optimization code. Deoptimization then transfers execution value of a constant, are enclosed in square brackets []. The inputs back to unoptimized code1. Such speculation is necessary to op- to an instruction are given in parentheses () and must be references timize for common cases that appear in JavaScript programs but to dominating instructions. The table also lists the effects changed that can nevertheless be violated by JavaScript’s extremely liberal and depended on for each instruction. Effects will be discussed in allowance for mutation. For example, unlike most statically-typed Section 2.2.2. We elide the discussion of the more than 100 real object-oriented languages, JavaScript allows adding and removing Crankshaft instructions which are not relevant to this paper. properties from objects by name, installing getters and setters (even for previously existing properties), and mutation of an object’s pro- 2.2 Global Value Numbering totype chain at essentially any point during execution. After adapt- The analysis required to detect opportunities for allocation folding ing to JavaScript’s vagaries, Crankshaft performs a suite of com- is implemented as part of the existing flow-sensitive global value mon classical compiler optimizations, including constant folding, numbering (GVN) algorithm in Crankshaft. Global value number- strength reduction, dead code elimination, loop invariant code mo- ing eliminates redundant computations when it is possible to do tion, type check elimination, load/store elimination, range analysis, so without affecting the semantics of the overall program. Extend- bounds check removal