Kasper lund october 4 2008
1 / 23

- PowerPoint PPT Presentation

  • Uploaded on

Kasper Lund October 4, 2008. V8: An Open-Source, High-Performance JavaScript Engine. Who Am I?. Kasper Lund, virtual machine addict 2000-2002: CLDC HI (Sun Microsystems) 2002-2006: Resilient (OOVM) 2006-2008: V8 (Google) Primary areas of interests: Dynamic programming languages

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about '' - oriana

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Kasper lund october 4 2008 l.jpg

Kasper Lund

October 4, 2008

V8: An Open-Source, High-Performance JavaScript Engine

Who am i l.jpg
Who Am I?

  • Kasper Lund, virtual machine addict

    • 2000-2002: CLDC HI (Sun Microsystems)

    • 2002-2006: Resilient (OOVM)

    • 2006-2008: V8 (Google)

  • Primary areas of interests:

    • Dynamic programming languages

    • Interpretation and dynamic code generation

    • Method dispatching

Challenges in implementing javascript l.jpg
Challenges in Implementing JavaScript

  • A very dynamic programming language

  • Objects contain properties (ie, fields or methods)‏

  • Properties can be added or removed on the fly

  • Objects with completely different sets of properties can appear at the same property access site

  • Properties can be found in an object's prototype chain

  • Functions can be moved from one object to another

Motivation for a new javascript engine l.jpg
Motivation for a New JavaScript Engine

  • When starting the project:

    • Browsers had slow JavaScript implementations

    • They did not scale to large applications with many objects

    • They even had memory leaks when running web apps

  • The solution seemed simple:

    • Build a completely new engine from the ground up

    • Find a way to categorize objects into classes

    • Bring to bear techniques from static class-based languages

V8 a scalable high performance js engine l.jpg
V8: A Scalable High-performance JS Engine

  • The goal was to raise the performance bar for JavaScript execution

  • Key design ideas in V8:

    • Hidden classes and hidden class transitions

    • Inline caching

    • Compilation to native code

    • Efficient memory-management system

Hidden classes l.jpg
Hidden Classes

  • In a static object-oriented language, a particular property is always found at a known offset in instances of a particular class

    • This is fast to access

  • In JavaScript, there are no classes

    • Objects appearing at a property access site may have a given property or not, found at various places in the object

    • This is slow - we need to speed it up

  • Hidden classes encode object layout and shared structure

    • Introduced behind-the-scenes

    • Enable class-based optimizations

Hidden classes7 l.jpg
Hidden Classes


function Point(x, y) {

this.x = x;

this.y = y;


var p = new Point(1, 2);

var q = new Point(3, 4);

Point p











Point q



How dynamic is javascript at runtime l.jpg
How Dynamic is JavaScript at Runtime?

  • Introducing hidden classes allows us to measure how many different classes are seen at a site in the code

  • Roughly 90% of all access sites see objects with the same hidden class

  • Conclusion:

    • JavaScript is not as dynamic at runtime as you might think

    • We can use class-based object-oriented optimization techniques

Inline caching l.jpg
Inline Caching

  • Each property access and function call is governed by an inline cache stub

  • Stubs are in one of three states:

    • Uninitialized: not executed yet

    • Monomorphic: only one class of objects seen

    • Megamorphic: more than one class of objects seen

Monomorphic stub for loading a property l.jpg
Monomorphic Stub for Loading a Property

0xf7c0d32d: [Code]Instructions (size = 37)0xf7c0d344 0 8b442404 mov eax,[esp+0x4]0xf7c0d348 4 a801 test al,0x10xf7c0d34a 6 0f8414000000 jz 320xf7c0d350 12 8178ff81ab8ff7 cmp [eax+0xff],0xf78fab810xf7c0d357 19 0f8507000000 jnz 320xf7c0d35d 25 8b5803 mov ebx,[eax+0x3]0xf7c0d360 28 8b4307 mov eax,[ebx+0x7]0xf7c0d363 31 c3 ret0xf7c0d364 32 e993daffff jmp LoadIC_Miss

Megamorphic state l.jpg
Megamorphic State

  • Lookup monomorphic stub in global lookup table

    • Hashed lookup based on address of class and hash code of the property name

  • Verify that the stub is suitable

    • Check that the stub type matches (load, store, call)

    • Check that the property name matches

  • Call the monomorphic stub

    • Class check automatically handled by the stub

    • Access is reasonably fast if all checks pass

Does it really matter l.jpg
Does It Really Matter?

  • Property load timings:

    • Monomorphic: 0.000249 usec

    • Megamorphic: 0.001390 usec (x5.5)

    • No inline caching: 0.008665 usec (x34.8)

  • Overall:

    • Inline caching speeds up benchmarks with a factor of ~11

    • Faster property access is important to real apps too

Native code compiler l.jpg
Native-code Compiler

  • JavaScript source code is translated directly into machine code

  • There is no intermediate bytecode, because there is no interpreter

  • Functions are compiled JIT-style

    • Source code is parsed into syntax trees

    • A simple one-pass code generator is used

    • Only a few optimizations are applied

  • Code generators are implemented for x86 and ARM

Efficient memory management l.jpg
Efficient Memory Management

  • Design goals:

    • Fast object allocation

    • Scalable object heap

    • Small garbage collection pause times

  • V8 uses a generational garbage collector

Object heap organization l.jpg
Object Heap Organization

  • Young Generation

    • New space: newly allocated objects, collected frequently

  • Old Generation

    • Code space: executable code objects

    • Old data space: objects with no pointers to the young gen.

    • Large object space: to avoid moving objects > 8KB

    • Hidden class space: requires special GC processing

    • Old pointer space: the rest of the old objects

Types of garbage collection l.jpg
Types of Garbage Collection

  • Scavenge collections are most frequent

    • Copying collector operating on the young generation

    • Allows single-pointer allocation

    • Pause times bounded by live data in young gen

    • Typical pause times: 1-2 ms

  • Mark-sweep collections for most full collections

    • Processes all spaces

    • Uses single-pointer and free-list allocation

    • Pause times bound by size of heap

    • Typical pause times: 30-50 ms

  • Mark-sweep-compact to eliminate fragmentation

    • Typical pause times: 50-150 ms

Where is the javascript library l.jpg
Where is the JavaScript Library?

  • All library functions are implemented in JavaScript

    • Examples: Array.prototype.join, String.prototype.replace

  • The benefits of not implementing it inside the engine:

    • Keeps the core engine cleaner

    • Easier to change and extend

    • Capitalizes on the performance of the JavaScript compiler

  • One drawback is startup time ~30 ms ...

    ... but there is a solution

Snapshotting of the object heap l.jpg
Snapshotting of the Object Heap

  • V8 allows saving the initial heap in a snapshot

    • Serialized form is very fast to read

    • Includes pre-compiled code for JavaScript builtins

    • Integrated in the build system and embedded directly in V8

  • With snapshots, the startup time is reduced to 4-8 ms

Open source l.jpg

  • Open-source code and developed in the open

    • Permissive standard three clause BSD license

    • Developed in the open, all code reviews are public

    • See http://code.google.com/p/v8

  • Interesting projects already using V8:

    • Chromium

    • V8R: Extensible JavaScript scripting shell

    • PyV8: Python running on top of V8

Benchmarks l.jpg

  • Benchmarking a new scripting engine is tricky

    • V8 is optimized for property accesses and function calls

    • No existing benchmark suites really exercise that

    • But it’s important to a lot of real world web apps

  • The industry needs realistic and well-written benchmarks

    • No single existing benchmark suite covers all of JavaScript

    • How do we go about measuring performance today?

Http code google com apis v8 run html l.jpg

  • Richards

    • OS kernel simulation benchmark, originally written in BCPL by Martin Richards (539 lines)‏

  • DeltaBlue

    • One-way constraint solver, originally written in Smalltalk by John Maloney and Mario Wolczko (880 lines)‏

  • Crypto

    • Encryption and decryption benchmark based on code by Tom Wu (1689 lines)‏

  • RayTrace

    • Ray tracer benchmark based on code by Adam Burmister (3418 lines)‏

  • EarleyBoyer

    • Classic Scheme benchmarks, translated to JavaScript by Florian Loitsch's Scheme2Js compiler (4682 lines)‏

Summary l.jpg

  • V8 is a high-performance JavaScript engine

    • Runs well-structured applications really fast

    • Raises the performance bar for scripting languages

    • Scales to larger applications

  • V8 is open-source and developed in the open

    • Embed it in your own projects

    • Use it for scripting on your computer

    • Incorporate the best ideas into your own scripting engine