A Comparison of JavaScript Engines

2010-07-19 00:00:00 +0100 by Alex R. Young

When I was writing the History of JavaScript series I
collected a lot of notes about JavaScript interpreters. If you're
wondering why people keep talking about V8 engines, monkeys and rhinos,
read on.

Name Type Garbage Collection Security Implemented In
Rhino Compiler and interpreter Java runtime SecuritySupport interface, domain-based Java
SpiderMonkey Compiler and interpreter Mark-and-Sweep, non-conservative (exact) collector Java principals security model C
V8 Virtual machine Generational stop-the-world collector Context-based, with security tokens C++

Engine Types

Rhino and SpiderMonkey can run as compilers or interpreters. They parse
JavaScript into an intermediate stage. V8 is different in that it has no
intermediate parser -- it generates assembler. This makes it sound more
like a compiler than anything, but it does include a runtime environment
of its own.

Garbage Collection

SpiderMonkey works by recursively searching all properties of all
objects in the current scope and deallocating any without references. V8
stops execution to reclaim memory, but it only usually processes part of
the heap to reduce the impact of stopping the program. The disadvantage
of V8's approach is that it has to stop the program -- imagine a
JavaScript program suddenly pausing and beachballing or egg-timering.
However, because it's simple, it's also fast.

Trace Trees

SpiderMonkey 1.8.1 has a just-in-time compiler that can convert bytecode
into machine code to improve performance. This was contributed by Adobe
and now co-maintained by Mozilla. The JIT watches for commonly executed
code and attempts to optimise the equivalent native code. The Tracing

page on Mozilla's site has more details.

This is one of the reasons that recent performance graphs show Mozilla's
JavaScript engines catching up with V8. V8's core innovation was
compiling straight into native code.