• Abstract and Figures
• Public Full-text

Browser Script Engines - EARLY DRAFT Mikko Rinne Department of Computer Science and Engineering Aalto University School of Science and Technology Espoo, Finland Email: mikko.rinne@tkk.fi Abstract—The abstract goes here. A. SpiderMonkey / TraceMonkey / Mozilla Firefox I. INTRODUCTION The tracing JIT-compiler will be new in SpiderMonkey 1.8.1, not released yet at the time of this writing [5]. It is All browser script engines, in practice, are built on EC- based on the work of Andreas Gal et al. [6]. MAScript [1] (MJR temp note: ECMAScript also available as (Note: The JavaScript TraceMonkey page states: ”As of a printed standard). Well-known variants in popular browsers 2009, of the stable builds only the 32-bit versions of Firefox include Microsoft JScript in Internet Explorer, ActionScript in have TraceMonkey available (use nightly builds for 64-bit Adobe Flash and Mozilla JavaScript in e.g. Firefox. [2] support).”, but the page is updated in October 2010???) The three main issues of focus in ECMA-script related 1) Dynamic Machine Code Generation (TraceMonkey): research have been security, correctness and performance. Identification of frequently executed loop traces is used at This literature survey on browser script engine implementation runtime to generate machine code on the fly. The code concentrates on the performance-enhancing features under is specialized for the actual dynamic types used on each development in different browser environments. These opti- path through the loop. Inter-procedural type specialization is mization techniques include construction of a dynamic type provided. There is also a method to incrementally compile system to avoid repeated dictionary lookups of objectives, and alternative paths through nested loops. [6] partial (pre-)compilation of the code with a JIT (just-in-time) JavaScript execution is started in a bytecode interpreter. compiler. [3] During execution, frequently executed sequences are identi- A. Not Part of Script Engine fied, recorded and compiled to fast native machine code. Such The Document Object Model (DOM), even though manipu- instruction sequences are referred to as traces [7]. lated by JavaScript, is typically provided by the browser. E.g. The compiler operates on individual loops with the expecta- in the case of V8, the DOM is provided by Chrome. [4] tion that most of program execution time is spent in hot loops. Hot loops are also expected to have good type stability. II. JAVASCRIPT CHALLENGES Trace creation takes the assumption that the path and typing The object system in JavaScript is extremely flexible. A will remain the same in all iterations of the loop. Every trace property, called using the context of its parent object is contains all the checks to validate the assumption. If control similar to a method in Java. Each object has a prototype flow is different or a value of a different type is generated, fieald referring to another object. A ”property lookup” involves the trace exits. ”If an exit becomes hot, the VM can record a searching the current object, then its parents in succession until branch trace starting at the exit to cover the new path. In this the property is found. way, the VM records a trace tree covering all the hot paths One of the main challenges in JavaScript compiler design through the loop.” are the highly dynamic variables. Several attempts at specify- The problem of nested loops is solved by recording nested ing type systems for JavaScript have been made (References trace trees. ”The system stops extending the inner tree when available from [3], if needed). it reaches an outer loop, starting a new trace at the outer loop Based on [3] use of the same library also emphasizes similar header. When the outer loop reaches the inner loop header, approaches to the coding of JavaScript. Such libraries include the system tries to call the trace tree for the inner loop.” If Objective-J (e.g. 280slides.com), jQuery (Digg, Twitter and the call succeeds, the call to the inner tree is recorded as part WordPress), Prototype (Xxx) and Closure (Google Maps, Mail of the outer trace, finishing the outer trace normally. With and Search). this approach any depth of nested loops can be traced without excessive tail duplication. III. BROWSER ENGINE PROPERTIES JIT compilation approaches were handled in more detail in Due to the dynamic nature of JavaScript allocations, most an earlier seminar [8]. engines use a dynamic lookup for accessing each object 2) Blacklisting [6]: Not all kinds of hot loops result in property. This slows down execution compared to more strictly a legal trace. Current TraceMonkey doesn’t support throwing typed languages, where instance variables can be stored at and catching of arbitrary exceptions, which are usually rare. fixed offsets. [4] However, if exceptions were repeatedly used by a program, a penalty would be observed, because the JIT compiler would runtime reaches an unitialized call site, the dynamic lookup is repeatedly try and fail. performed and the result as stored at the call site, changing The prediction algorithm in TraceMonkey is able blacklists state to ”monomorphic”. If the runtime reaches the same call traces, whose compilation has not succeeded. In case of failure, site again, the callee can be directly invoked without further the trace starting point is recorded. A new trace will not be lookups. recorded at that point until it is passed a few more times (e.g. Some guard conditions are needed for protection against the 32 in the example), which gives a back-off property in case possibility that objects of different types occur at the same call the trace was prevented by temporary conditions. site. The more common way is to apply such guard conditions to the preamble of the callee rather than at the call site to B. V8 / Google Chrome better exploit branch prediction and save space (one copy in 1) Hidden classes: To avoid spending time with dictionary the preamble vs. multiple copies at call sites). If a call site in lookups of dynamic objects, Google V8 dynamically creates ”monomorphic” state encounters a type other than the one it ”hidden classes”, which change with the addition of a new expects it changes back to uninitialized and performs a new property. The following example is presented in [4]: full dynamic lookup. Consider a new object of type ”point” being created: 3) Dynamic Machine Code Generation: In V8 JavaScript is function Point(x, y) { compiled directly into machine code upon the first execution. this.x = x; No intermediate byte codes nor an interpreter are being used. this.y = y; Property access is handled by inline cache code, which can be } patched with other machine instructions during V8 execution. First V8 determines the current hidden class status of an The ”Point” object could be initially associated with a class object. It assumes that the same class will also be used for all C0. If a new property is created with Point (this.x = future objects accessed in the same call site. This information x;), a new hidden class C1 is created, with the value of is used to patch the inline cache code to use the appropriate property x stored at offset zero in the Point object. At the hidden class. If the assumption is correct, the value of the same time C0 is updated with a class transition indicating that property can be assigned or fetched in a single operation. If C0 with property x points to C1. The situation after addition not, the code is patched to remove the optimisation. of one more property y and creation of another hidden class The following example is given in [4]: C2 is shown in Figure 1. The JavaScript code to access property x from a Point object would be For example, the JavaScript code to access property x from A Point Object Hidden Class C2 a Point object would be point.x Class pointer For x see The V8 machine code for accessing x would be: offset 0 Offset 0: x Hidden Class C1 For y see Offset 1: y offset 1 # ebx = the point object For x see cmp [ebx,<hidden class offset>], offset 0 Initial hidden <cached hidden class> Class C0 If you add propert y, jne <inline cache miss> If you add transition to property x, class C2 transition to mov eax,[ebx, <cached x offset>] class C1 In case the hidden class of the point object wouldn’t match the hidden class, execution would jump to the runtime system, Fig. 1. Hidden class creation with additional properties which would patch the inline cache code. If the hidden class matches, which is hoped to be the most common case, the Googles V8 associates classes with objects, assuming that value of property x is retrieved. their shape will not change too much. Highly dynamic objects Especially in the case of many objects sharing the same are treated as fallback cases. [3] hidden class, the benefits are similar to the ones obtained in 2) Inline caching: Hidden classes also enable V8 to make static languages. The combined use of hidden classes, inline better use of inline caching [9]. In inline caching the results caching and machine code generation optimises for cases of a previous method lookup are stored directly at the call where the same type of object is frequently creted and accessed site. This is especially useful for dynamically typed languages, in a similar way. where the method binding typically happens at runtime. 4) Garbage Collection Optimizations: V8 stops program Inline caching is supported by the observation that objects execution during garbage collection. The object heap is seg- occurring on a particular call site are often of the same type, in mented into two parts: New objects are created in a ”new which cases large performance improvements can be achieved.

Load more

  4

Copy Link