V8: The JavaScript Engine Inside Google Chrome

by Lars Bak, Google Aarhus

Copyright Google 2008 1

Users Spend More Time Inside the Browser

Users are spending more and more time online

Web has evolved from early days of text pages to richer, more
interactive web applications
 Gmail
 Flickr
 Amazon

Most people do not realize that the underlying browser

architecture has evolved much more slowly

Copyright Google 2008 2

Choice and Competition Helps User Experience

Copyright Google 2008 3

Introduction to Google Chrome

Google Chrome is a new open-source browser

 Simple user experience
 Based on Webkit open source project
 Multi-process architecture
 Renderers are running in sandboxes
 ... a brand new JavaScript engine

Beta release has been available for three weeks

 Including all the source code with a BSD license

Copyright Google 2008 4

Motivation for a New JavaScript Engine

When starting the project the picture was grim:

 Browsers had slow JavaScript engines
 These engines did not scale well with code and objects
 Browsers had memory leaks when running web applications

The solution seemed simple:

 Design a new JavaScript engine based on well-known
techniques
 .. but we had to find a way to categorize objects

Copyright Google 2008 5

Challenges in Implementing JavaScript

Very dynamic programming language

Properties are added, changed, and removed on-the-fly
 Sometimes objects are even used as dictionaries
Properties in prototypes change on-the-fly
Functions can be moved from one object to another
JavaScript source code is input to the engine

... and JavaScript is sort of strange:

var x = 1
x.y = 2
print(x.y)

Copyright Google 2008 6

Designing a Fast JavaScript Engine

•Focus on making large object-oriented programs perform well:

• Fast property access
• Fast function calls
• Fast memory management

We wanted to make factored JavaScript code run fast

Copyright Google 2008 7

V8: A Scalable High Performance JavaScript Engine

The goal was to increase the performance bar for JavaScript

execution

• Key design ideas behind V8:

• Hidden class transitions
• Dynamic machine code generation
• Efficient memory management system

Copyright Google 2008 8

V8 Object Model

•Tagged 32 bit memory model:

•Small integers are immediate values:

31-bit signed value 0

•Heap objects are 4 byte aligned so pointers are:

Direct memory address 01

• JavaScript object representation:

Class (x,”first”) (y,”second”)
Named
Indexed (0,23) (1,45) (2,12)
Copyright Google 2008 9
Hidden Classes

•Original idea from Self where maps were used for shared state

•Share structure between similar objects

•In most OO language, an instance variable is located a fixed

offset of an instance -> fast access

•In JavaScript, there are no classes. Properties are dynamically

added -> slow access

Copyright Google 2008 10

Hidden Class Transitions

Class0
function Point(x, y) { Δx

this.x = x;

this.y = y; Class1
Point p Point q
{x:0}
}
Δy
⊥
1 ⊥
3
⊥
2 ⊥
4
var p = new Point(1, 2);
⊥ Class2 ⊥
var q = new Point(3, 4); {x:0, y:1}

Copyright Google 2008 11

Objects May Degenerate

•An object may be used as a dictionary

•V8 recognized this at runtime

•Backing storage for the object is then converted into slow dictionary
implementation
• Adding or deleting properties will not change its map

Copyright Google 2008 12

How Dynamic is JavaScript at Runtime?

Introducing hidden classes allow us to measure how many

different classes are seen at one point in the code

Roughly 90% of all code points only see objects with the same
hidden class

Conclusion
 JavaScript is NOT as dynamic at runtime as you would think
 Opens up for class based object-oriented optimizations

Copyright Google 2008 13

Stub Based Inline Caching

•Inline caches used for capturing the receiver type at each:

• Property load
• Property store
• Property call

Code for inline caches are generated in stubs:

• Allows for code sharing and reduces code size

Inline cache stubs check prototype chains are valid

Copyright Google 2008 14

Stub Based Inline Caching

•Each function call and property access is controlled by an inline

cache stub
1.Uninitialized state
2.Mono-morphic state (very fast)
3.Mega-morphic state
Global hash table is used for resolution
Inline cache stubs are reused as targets

Copyright Google 2008 15

Inline Cache Code for Loading a Property
•Generated code for loading point.x:
•0xf7c0d312 call 0xf7c0d344

•Inline cache stub:

•0xf7c0d344 mov eax,[esp+0x4]
•0xf7c0d348 test al,0x1
•0xf7c0d34a jz 32
•0xf7c0d350 cmp [eax+0xff],0xf78fab81
•0xf7c0d357 jnz 32
•0xf7c0d35d mov ebx,[eax+0x3]
•0xf7c0d360 mov eax,[ebx+0x7]
•0xf7c0d363 ret
•0xf7c0d364 jmp LoadIC_Miss

Copyright Google 2008 16

Native Code Generator

•JavaScript source code is translated directly into machine code

•Skips the intermediate bytecode level since no interpreter is

needed

•Functions are compiled JIT style

• Source code is first converted into standard AST
• Simple one-pass compiler generate native code
 Only few local optimizations are applied

Code generators are available for ARM and x86

Copyright Google 2008 17

Efficient Memory Management

•Design goals:
• Fast object allocation
• Make the object heap scalable
• Make most garbage collection pauses small

•The simple garbage collector solution:

• Stop the world
• Single threaded
• Generational enabled by a write barrier

Native code including inline cache stubs are in the heap

Copyright Google 2008 18

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

Copyright Google 2008 19

Types of Garbage Collection

•Scavenge collections are most frequent:

• Copying collector operating on new space
• Pause times bound by amount of live data in new space
• Typical pause times: 1-2 ms

•Mark-sweep collections for most full collections:

• Processes all spaces
• Pause times bound by size of heap
• Typical pause times: 30-50 ms

•Mark-sweep-compact collections for eliminating fragmentation:

• Like mark-sweep but with compaction
• Typical pause times: 50-150 ms

Copyright Google 2008 20

Where is the JavaScript Library?

•All library functions are implemented in JavaScript!

• Examples: String.prototype.match and Array.prototype.join

•The benefits of not implementing it inside the engine:

• Keeps the core engine cleaner
• Easier to change
• Capitalize on the performance of the JavaScript compiler
• Enables lazy loading of libraries

Copyright Google 2008 21

JavaScript Library Example

•Date library is implemented this way

•// ECMA 262 - 15.9.5.30

•function SetSeconds(sec, ms) {
• var t = LocalTime(GetTimeFrom(this));
• sec = ToNumber(sec);
• ms = %_ArgumentsLength() < 2
• ? GetMillisecondsFrom(this)
• : ToNumber(ms);
• var time = MakeTime(HourFromTime(t), MinFromTime(t), sec, ms);
• return %_SetValueOf(this, TimeClip(UTC(MakeDate(Day(t),
time))));
•};

•The only drawback is slower startup ~30 ms ...

•... but there is a solution

Copyright Google 2008 22

Snapshotting of the Object Heap

•V8 allows storing the initial object heap in a snapshot

• Serialized form is very fast to read in
• Includes pre-compiled code for builtin JavaScript functions
• Integrated in build system and embedded directly in V8
 Build command: scons snapshot=on

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

Copyright Google 2008 23

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

• Check out the complete source code for V8

• Changes from the V8 team does directly to this repository
• BSD source code code license
• The open source project for Google Chrome is located at:
 http://chromium.org/

Copyright Google 2008 24

V8 Benchmark Suite

•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)

Copyright Google 2008 25

Future Directions for V8

•New compiler infrastructure for better code quality

•Reimplement regular expressions in JavaScript

•Partial snapshot for instant startup

•Integrate DOM nodes into JavaScript object heap

Copyright Google 2008 26

Summary

•V8 is built for speed and scalability

•V8 is ready for next generation web applications

•V8 is fully open source and we hope you will contribute

•V8 is embeddable with a clean API

... and by the way, we've just started tuning it

Copyright Google 2008 27

Q&A Session About V8

Copyright Google 2008 28