Gadget 54：What is Chrome V8?

JavaScript/WebAssembly エンジン Chrome V8 を深掘り。Workers がなぜ速いのかの土台を理解する

What is Chrome V8?

Cloudflare Workers を速く動かす「心臓部」、Chrome V8 を深掘りします。

目的

  • V8 が「何をしているエンジン」かを正確に理解する
  • Workers / workerd の「コールドスタート」「分離」「速度」の背景が説明できる

前提条件

V8 とは

  • Google 製のオープンソース JavaScript / WebAssembly エンジン（C++ 実装）
  • Chrome / Node.js / Deno などのほか、Cloudflare Workers のランタイム（workerd） も内部で V8 を利用
  • JavaScript コードを機械語レベルまで最適化して実行できる

どこで動いているか

ホスト V8 が担う役割
Chrome ページの JS を解釈・実行
Node.js / Deno サーバー側 JS の実行
workerd（Workers） エッジ上の Worker コードを V8 isolate として実行

中身のしくみ（ざっくり）

2 段階の実行パイプライン

  1. Ignition（インタプリタ）: まずバイトコードとして素早く実行開始
  2. TurboFan（JIT コンパイラ）: ホットなコードを機械語に最適化コンパイル
  • 最適化の前提（ヒドゥン クラス・インラインキャッシュ）が崩れると deoptimization が起き、あっさり遅くなる
  • つまり「コードの書き方しだいで速くなる/遅くなる」

メモリ管理（Orinoco GC）

  • Young（新生代）: 短命の値。Scavenger（Minor GC）が素早く回収
  • Old（老年代）: 生き残った値。Mark-Sweep（Major GC）で回収
  • アプリ側から「GC を明示制御」は基本できない → メモリ消費に気をつける設計が必要

Isolate という分離単位

  • V8 は isolate（実行コンテキストの分離領域）単位で JS を動かす
  • Workers の「1 リクエスト = 1 isolate」的な分離はこの仕組みが元
  • 別 isolate はメモリも状態も独立 → サンドボックスの説明がつく

手順（体感する）

1. 利用中エンジンの V8 バージョンを見る

# Node.js
node -e "console.log(process.versions.v8)"

# ブラウザ（コンソールで）
# navigator.userAgent や Chrome の chrome://version で確認可能

2. workerd / Workers のコールドスタートを考える

  • コールドスタート = 新しい isolate を立ててコードを起動すること
  • V8 は「コールドスタートを速くする」ためにコンパイルを遅延／断片化（Lazy 系最適化）
  • 「最初の呼び出しだけ遅い」現象はこの設計と相関（14）

3. 最適化を意識した書き方の例（体感）

// ヒドゥン クラスを保つ＝形を揃える
// GOOD: 一度作ったオブジェクトの形を後から変えない
const item = { id: 1, label: "a" };
// BAD: 同じ関数で扱うオブジェクトの形をバラバラにしない

よくある失敗

症状 原因 対処
V8 を「JavaScript 言語」と誤解 エンジンと言語の混同 V8 は「JS/WebAssembly を実行するエンジン」
動くだけで速いと錯覚 JIT 前提の理解不足 ホットパスで形を揃えるコードを心がける
メモリが増える GC を制御できると誤解 大きなデータは R2/D1 へ（39/38）
コールドスタートをコード起因と思い込む 設計起因のものもある isolate 起動・依存ロード量を疑う

確認

次に読む