69. JavaScriptCore and SpiderMonkey

One loop, three engines

Every number this book has measured came from Node, which runs V8. Open the same page in Safari and JavaScriptCore runs it. In Firefox, SpiderMonkey does. All three follow one specification^[13], so your program prints the same thing everywhere. Nothing in that specification says how fast anything must be.

So is struct-of-arrays faster in Safari too? This book never measured it, and this chapter won’t pretend. What it can do is show you, from the engines’ own source code, how differently they are built. Then “it was 4× faster on my machine” stops sounding like a law of nature.

Same ladder, different rungs

Chapter 61 climbed V8’s ladder: Ignition, then Sparkplug, Maglev and TurboFan^[1]. Step through all three engines:

JavaScriptCore has four tiers. Its option list names them: the LLInt, the Baseline JIT, the DFG JIT and the FTL JIT^[3]. The LLInt (“low-level interpreter”) isn’t written in C++. It is written in an assembly-like language of JavaScriptCore’s own, with macros and per-platform ifs, which is translated for each processor^[4]. The same option list shows that even this interpreter has inline caches for property accesses and calls. At the top, the FTL takes the DFG’s view of a function and lowers it into a second intermediate representation, the compiler’s private form of the program (Part VI is all about them), called B3, for heavier optimization^[6].

SpiderMonkey has a C++ interpreter, a Baseline Interpreter, a Baseline JIT and an optimizing compiler, Ion. Its options file states the default warm-up counts:

// js/src/jit/JitOptions.cpp, trimmed
// "invocations or loop iterations"
SET_DEFAULT(
  baselineInterpreterWarmUpThreshold, 10);
SET_DEFAULT(
  baselineJitWarmUpThreshold, 100);
SET_DEFAULT(
  normalIonWarmUpThreshold, 1500);

Each count is “invocations or loop iterations”^[8]. The front end of Ion is called Warp. Its oracle takes a snapshot of what the Baseline inline caches saw, and WarpBuilder turns the bytecode into Ion’s own representation off the main thread^[9]. Those caches are written in CacheIR, “an (extremely simple) linear IR language for inline caches” (IR: intermediate representation), from which both Baseline and Ion produce machine code^[10].

Where a failed guess lands

All three speculate (chapter 66), and all three can be wrong. What differs is where they go back to. V8’s deoptimizer rebuilds interpreter frames^[1]. JavaScriptCore’s DFG code describes “how to exit the speculative path by going into baseline code”^[5]. In SpiderMonkey, a bailout recovers “a baseline interpreter frame” from Ion’s frame, for example when a shape guard fails or an integer add overflows. Values may be unboxed or optimized away, and inlined frames may be missing, so small snapshots record how to rebuild each one^[11].

Same number, three encodings

Tiers aren’t the only difference. Even a single value is stored differently. Chapter 22 showed V8’s choice: a small integer is a Smi, and a double usually lives in a separate HeapNumber. Chapter 60 showed SpiderMonkey’s: every value is NaN-boxed, with a tag in the high bits of a double^[12].

JavaScriptCore also uses NaN space, but the other way round. A pointer is stored as it is, so its top 16 bits are zero. A 32-bit integer gets the tag 0xFFFE on top. A double is stored as its own bits plus 2⁴⁹, which moves every real double out of both of those ranges. Decoding subtracts it again^[7]. Adding 2⁴⁹ to a 64-bit pattern adds 0x20000 to its high 32-bit word, so a typed-array view (chapter 16) can show it:

const f64 = new Float64Array(1);
const u32 = new Uint32Array(f64.buffer);
const hex = (n) =>
  n.toString(16).padStart(8, '0');

// int32: tag 0xFFFE on top
function jscInt(i) {
  return 'fffe0000:' + hex(i >>> 0);
}
// double: its bits plus 2^49, which is
// 0x20000 in the high 32-bit word
function jscDouble(d) {
  f64[0] = d;
  const raw = u32[1];
  const hi = (raw + 0x20000) >>> 0;
  return hex(raw) + ' -> ' +
    hex(hi) + ':' + hex(u32[0]);
}

console.log('5   ', jscInt(5));
console.log('-1  ', jscInt(-1));
console.log('1.5 ', jscDouble(1.5));
console.log('-2.5', jscDouble(-2.5));
console.log('NaN ', jscDouble(NaN));

Your turn

const f64 = new Float64Array(1);
const u32 = new Uint32Array(f64.buffer);
const INT_TAG = 0xfffe0000;
// 2^49, as seen in the high word:
const OFFSET = 0x20000;

function encode(v) {
  return [0, 0];
}

function decode(hi, lo) {
  return 0;
}

const SM = [
  ['interpreter', 0],
  ['baseline interpreter', 10],
  ['baseline jit', 100],
  ['ion', 1500],
];

function tierAt(n, ladder) {
  return ladder[0][0];
}

What you learned

• JavaScriptCore runs code in the LLInt, the Baseline JIT, the DFG JIT and the FTL JIT. The LLInt is written in its own portable assembly language. The FTL lowers the DFG’s view of a function into B3.
• SpiderMonkey has a C++ interpreter, the Baseline Interpreter, the Baseline JIT and Ion, whose front end Warp compiles from snapshots of baseline CacheIR caches.
• A failed guess resumes in V8’s interpreter, JSC’s baseline code, or SpiderMonkey’s Baseline Interpreter.
• JSC NaN-encodes values with raw pointers, 0xFFFE-tagged int32s and doubles offset by 2⁴⁹.
• Engine diversity: one spec, many designs. A speed-up measured in one engine is a hypothesis in another.