三个公式 — WebAssembly 到底是什么

Three formulas — what WebAssembly really is

把这个庞然大物压成三行

crushing the elephant into three lines

主流引擎的「Tier 拓扑」对照

Engine tiering at a glance

从这张表里冒出一个事实:浏览器三家都选择了"双层 JIT",非浏览器引擎多半只留一层优化器或反而留解释器。原因是浏览器要兼顾"开页面要立刻能跑"和"久了要够快",而服务器端 wasm 通常是冷启动一次跑很久,直接 AOT 即可。同一个 spec,生出两套截然不同的实现哲学。

A fact climbs out: all three browser engines went with two-tier JIT, while non-browser engines tend to keep just one optimiser — or revert to an interpreter. Browsers must reconcile "must run instantly" with "must run fast eventually"; server-side wasm cold-starts once and runs forever, so AOT alone is enough. One spec, two diverging philosophies of implementation.

WebAssembly 不是一种语言,
是一份让 LLVM 和浏览器握手的协议。 Field Note · 03

WebAssembly is not a language.
It is the handshake between LLVM and the browser. Field Note · 03

家谱 — 从 asm.js 到 wasm-GC 的十三年

A family tree — 13 years from asm.js to wasm-GC

每一个提案都是一次妥协的化石

every proposal is a fossilised compromise

三个不能略过的祖先

Three ancestors you cannot skip

提案的四个阶段

The four phases of a proposal

CG = Community Group(社区组,任何人可加入);WG = Working Group(工作组,需要会员资格)。一个提案常常在 phase 3 待两到三年——SIMD 在 phase 3 待了 26 个月才升 phase 4。这套机制让 wasm 的每一步演进都需要至少两家厂商先实现,从根上把"一家独大"挡住了。

CG = Community Group (anyone can join); WG = Working Group (membership required). A proposal often sits in phase 3 for two to three years — SIMD spent 26 months at phase 3 before stepping up. The mechanism forces every evolutionary step to be implemented by at least two vendors first — structurally blocking unilateral moves.

为什么是栈机 — 一个 1980 年代的选择

Why a stack machine — a choice from the 1980s

JVM 走过的路,wasm 又走了一遍

JVM walked this path, wasm walked it again

两种机器的编码密度对比

Encoding density: stack vs register

考虑一行表达式 c = a + b。在两种 ISA 里它的字节序列分别是:

Take a single expression c = a + b. The byte sequences in the two ISAs:

看起来寄存器机指令更少。但寄存器号需要 bits 来编:LLVM 的 SSA 寄存器数量无界,实际编码时需要 32 位甚至更多;Dalvik 把寄存器限到 256 个,8 bit;ARM/x86 真寄存器 16 个,4 bit。栈机一字节就是一条 opcode(i32.add = 0x6A),局部变量索引用 LEB128(通常 1 byte),整体下来栈机一般赢 30~40% 字节。

Register ops look fewer. But register IDs need bits: LLVM SSA values are unbounded, encoded at 32+ bits each; Dalvik caps at 256 registers (8 bits); ARM/x86 have 16 real registers (4 bits). A stack-machine opcode is one byte (i32.add = 0x6A), local indices LEB128 (usually 1 byte). The stack form typically wins 30–40% on bytes.

栈机的四个"赠送好处"

Four bonuses the stack throws in for free

但栈机有一个老问题

But the stack has one old problem

栈机解释执行慢——每条指令要操作栈顶,栈本身常驻内存,L1 cache 命中率不如寄存器机。这是 JVM 早期被嘲讽"慢得像树懒"的根本原因。wasm 怎么解?用 JIT 而不是解释器。设计者赌的是:既然反正都要 JIT,那就让字节码偏向解码密度,机器码偏向执行速度,各取所长。

Stack interpreters are slow — every op touches the stack top, the stack lives in memory, L1 hit-rate trails register machines. That's why early JVMs felt "sloth-slow". Wasm's answer: skip the interpreter. The bet was: we'll JIT anyway, so let the bytecode optimise for density and the machine code optimise for speed. Best of both.

栈机还配了一个"半寄存器"层:locals。每个函数有固定数量的 locals(像寄存器),local.get / local.set 在栈和 locals 之间搬运值。这套设计让 wasm 既像栈机一样紧凑,又像寄存器机一样能"存中间结果"。JVM 的 locals 与之几乎完全相同——wasm 的设计者把 JVM 学了一遍。

Stack machines also carry a "half-register" file: locals. Each function has a fixed number of locals (register-like), with local.get / local.set moving values between stack and locals. That gives wasm a stack's compactness with a register machine's ability to "hold intermediate values". The JVM has the exact same construct — wasm's designers studied JVM thoroughly.

栈是密度,寄存器是速度。
wasm 选了让编译器付出速度。 Field Note · 03

The stack buys density, the register buys speed.
Wasm chose to make the compiler pay for speed. Field Note · 03

JS 的天花板 — JIT 再聪明也跨不过的三件事

JS ceiling — three things even a brilliant JIT can't climb

为什么 wasm 必须存在

why wasm has to exist

三个具体的天花板

Three concrete ceilings

数字:wasm 比 JS 快多少

By how much, in numbers

表里最后一行是反例:DOM diff 在 wasm 里反而更慢,因为每次 DOM 调用都要跨 wasm/JS 边界,trampoline 成本压过了算术加速。wasm 比 JS 快的是"算数",不是"调用浏览器 API"——这条边界 Ch17 会量化。

The last row is a counter-example: wasm is slower at DOM diff, because each DOM call crosses the wasm/JS boundary, and the trampoline cost outweighs the arithmetic speedup. Wasm beats JS at arithmetic, not at calling browser APIs — Ch17 quantifies that boundary.

The Hot Loop — 一段 3×3 卷积的来生

The Hot Loop — afterlife of a 3×3 convolution

11 行 Rust,17 道工序,1 条 SSE 指令

11 lines of Rust, 17 stages, 1 SSE op

源码 · hot.rs

Source · hot.rs

// hot.rs — 3×3 box blur on an 8-bit grayscale image
// w · h are pre-checked, no panics on bounds

#[no_mangle]
pub fn blur3(src: &[u8], dst: &mut [u8], w: usize, h: usize) {
    for y in 1..h - 1 {
        for x in 1..w - 1 {
            let mut sum: u32 = 0;
            for dy in 0..3 {
                for dx in 0..3 {
                    sum += src[(y + dy - 1) * w + (x + dx - 1)] as u32;
                }
            }
            dst[y * w + x] = (sum / 9) as u8;
        }
    }
}

五个观察:① #[no_mangle] 让 rustc 把符号名原样导出,后面 wasm 才能用 blur3 找到它;② 输入是切片,Rust 编译到 wasm 时会拆成"指针 + 长度"两个 i32 参数;③ 内层 9 次 src[...] 索引,每次都会被 LLVM 展平成 i32.load offset=?;④ sum / 9 编译成 i32.div_u——不是浮点;⑤ Rust 的 as u8 编译成 i32.store8,只写低 8 位。这五件事每一件都对应 wasm 的一个设计点,后面会一个个回到。

Five observations: ① #[no_mangle] tells rustc to export the symbol literally so wasm callers can find blur3; ② slice arguments are split into "pointer + length" — two i32 args each; ③ the nine inner src[...] indices each flatten into i32.load offset=?; ④ sum / 9 becomes i32.div_u — integer, not float; ⑤ as u8 becomes i32.store8, writing only the low byte. Each of these maps to a wasm design choice; we'll come back to them one by one.

编译命令 · 一行 rustc

Build command · one rustc invocation

$ rustc --target wasm32-unknown-unknown -O --crate-type cdylib -o hot.wasm hot.rs
$ wasm-opt -O3 hot.wasm -o hot.opt.wasm    # Binaryen post-pass
$ ls -l hot*.wasm
-rw-r--r--  1 airing  staff  192 May 16 14:32 hot.opt.wasm
-rw-r--r--  1 airing  staff  248 May 16 14:32 hot.wasm

192 字节的 .wasm 包含完整的模块——header / type / function / memory / export / code 六个 section,加起来不到一条 tweet。这是栈机+LEB128 编码密度的胜利。把这 192 字节十六进制打印出来,你能眼睛看完:

192 bytes contains the entire module — header / type / function / memory / export / code, six sections, less than a tweet. That's the win from stack machine + LEB128. Print those 192 bytes as hex and you can read them with your eyes:

00000000  00 61 73 6d  01 00 00 00  ; \0asm magic + version=1
00000008  01 0b 02      60 04 7f 7f  ; type section, 2 types
00000010  7f 7f 00     60 00 00     ; (func (param i32 i32 i32 i32)), (func)
00000018  03 02 01 00                  ; function section: func0 has type0
0000001c  05 03 01 00 01              ; memory section: 1 page (64 KiB)
00000021  07 09 01      05 62 6c 75  ; export "blur3"
00000029  72 33 00 00                  ; → func 0
0000002d  0a ...        ; code section, body of blur3 (155 byte)
...
000000be  0b                          ; end · final byte = 0xC0 (192)

注意三件事:① 00 61 73 6d 是 ASCII 的 \0asm——所有 wasm 模块都以它开头,像 ELF 的 0x7F ELF;② 01 00 00 00 是版本号 1,小端;③ 每个 section 以一个 ID byte(0x01 = type, 0x03 = function, ...)开头,然后是 LEB128 编码的长度。Ch06 会把这层皮一字一字撕开。

Three things to note: ① 00 61 73 6d is ASCII \0asm — every wasm module starts with it, like ELF's 0x7F ELF; ② 01 00 00 00 is version 1, little-endian; ③ each section opens with an ID byte (0x01 = type, 0x03 = function, …) followed by LEB128-encoded length. Ch06 peels this skin off byte by byte.

作为 wat 文本(人类可读)

As wat text (human-readable)

;; hot.wat — 经过 wasm-opt -O3 优化后的等价文本
(module
  (type $t0 (func (param i32 i32 i32 i32)))
  (memory (export "memory") 1)
  (func $blur3 (export "blur3") (type $t0)
    (param $src i32) (param $dst i32)
    (param $w   i32) (param $h   i32)
    (local $y i32) (local $x i32) (local $sum i32)
    ;; for y = 1..h-1
    (local.set $y (i32.const 1))
    (block $break_y
      (loop  $loop_y
        (br_if $break_y (i32.ge_s (local.get $y) (i32.sub (local.get $h) (i32.const 1))))
        ;; for x = 1..w-1
        (local.set $x (i32.const 1))
        (block $break_x
          (loop  $loop_x
            (br_if $break_x (i32.ge_s (local.get $x) (i32.sub (local.get $w) (i32.const 1))))
            ;; sum = 9 个 load 加起来 (LLVM 已经把内 2 层循环展平)
            local.get $src
            i32.const 0
            i32.load8_u offset=0      ;; src[(y-1)*w + (x-1)]
            local.get $src
            i32.load8_u offset=1
            i32.add
            ;; ... 共 9 次 i32.load8_u + 8 次 i32.add ... (展开版省略)
            local.set $sum
            ;; dst[y*w + x] = sum / 9
            local.get $dst
            local.get $sum
            i32.const 9
            i32.div_u
            i32.store8                ;; 写回
            local.set $x (i32.add (local.get $x) (i32.const 1))
            br $loop_x)) ;; end x
        local.set $y (i32.add (local.get $y) (i32.const 1))
        br $loop_y))                ;; end y
)

这是 wat 的一种展开形式(为了讲解可读)。实际的 LLVM 输出会把内 2 层循环完全展开成 9 条 i32.load8_u + 8 条 i32.add。注意三个关键点:(a) 控制流只有 block / loop / br / br_if 这几个原语——没有 goto;(b) 所有内存访问都带 offset=N,这个 offset 是编译期常量,Liftoff 可以直接折进地址计算;(c) 每条算术指令的输入输出类型由 opcode 自身决定(i32.add 必然两 i32 输入一 i32 输出)——这是 wasm "静态类型"的核心,Ch08 和 Ch11 会展开。

This is wat in an unrolled-but-readable form. The real LLVM output unrolls the two inner loops into 9 × i32.load8_u + 8 × i32.add. Three key things: (a) control flow uses only block / loop / br / br_if primitives — no goto; (b) every memory access carries an offset=N immediate that is a compile-time constant, which Liftoff folds straight into address arithmetic; (c) each arithmetic opcode self-describes its operand types (i32.add is always two-i32-in, one-i32-out) — that's the core of wasm's static typing, expanded in Ch08 and Ch11.

在 V8 里跑出的机器码 · Liftoff(Tier 0)

Machine code in V8 · Liftoff (Tier 0)

把 hot.wasm 喂给 V8,默认会先用 Liftoff 编译。在 Chrome 里用 --print-wasm-code dump 出 Liftoff 生成的 x86-64:

Feed hot.wasm to V8 and Liftoff compiles first by default. Use --print-wasm-code in Chrome to dump the generated x86-64:

; Liftoff output for blur3 (excerpt of inner body)
push   rbp
mov    rbp, rsp
sub    rsp, 0x30                ; reserve 6 slots for locals
mov    [rbp-0x08], rdi          ; spill $src (arg 0)
mov    [rbp-0x10], rsi          ; spill $dst (arg 1)
...
; inner: load src[idx]
mov    rax, [rbp-0x08]          ; rax = $src
mov    rcx, [rbp-0x18]          ; rcx = computed index
movzx  edx, byte ptr [r15+rax+rcx]   ; bounds-check via r15 base
add    [rbp-0x28], edx          ; sum += byte
...
; tier-up trigger
cmp    dword ptr [r13+0x40], 0x100
jne    +0x4
call   WasmCompileLazy

Liftoff 的输出有几个标志:(1) 几乎所有局部变量都 spill 到栈上,不做寄存器分配——这让 codegen 走单遍;(2) r15 是 V8 约定的 "wasm memory base" 寄存器,所有 load/store 都通过它做基址相对寻址,自带越界检查(用大段保留页 + signal handler);(3) 函数尾巴塞了一个 tier-up 计数器,每次进入函数就 cmp 一下,达到阈值就触发后台 TurboFan 重编译——这是 Ch14 / Ch15 的故事。

Marks of Liftoff: (1) nearly every local spills to the stack — no register allocation, single-pass; (2) r15 is V8's "wasm memory base" register; every load/store uses it as the base, with bounds checking via guard pages + signal handlers; (3) the function tail packs a tier-up counter, cmp'd on each entry — when the threshold trips, a background TurboFan recompile fires. That's the Ch14 / Ch15 story.

同一个函数,经 TurboFan 重编译(Tier 1)

Same function, TurboFan-recompiled (Tier 1)

; TurboFan output for blur3 (excerpt of inner body)
mov    edi, [r15+rcx]           ; row 0 starting load — held in reg, not spilled
movzx  eax, dil
movzx  ebx, byte ptr [r15+rcx+1]
add    eax, ebx                 ; 9 loads, 8 adds — all in regs
movzx  ebx, byte ptr [r15+rcx+2]
add    eax, ebx
...
mov    ebx, 0x1c71c71d          ; (2^32 + 8) / 9 magic for div-by-9
mul    ebx
shr    rdx, 1
mov    byte ptr [r15+rdi], dl   ; store the average
add    ecx, 1                   ; x++
cmp    ecx, esi
jl     -0x53

TurboFan 输出几乎就是手写汇编的样子——寄存器分配把 9 次 load 的中间结果留在 eax/ebx 里,sum / 9 被识别成"除以常数",用魔数乘法(0x1c71c71d)替换了昂贵的 div 指令。这一招 LLVM 也会做(Hacker's Delight 第 10 章),V8 的 TurboFan 把它原样搬过来。这是 wasm "原生 80%" 的具体形式。

TurboFan output reads like hand-written assembly — the register allocator keeps the 9 loads in eax/ebx, and sum / 9 is recognised as "divide by constant" and replaced with magic-number multiplication (0x1c71c71d). LLVM does the same trick (Hacker's Delight Ch10); V8 ports it over. This is the concrete form of wasm's "80% of native".

和 SIMD 版本的对比

vs the SIMD version

如果你打开 RUSTFLAGS="-C target-feature=+simd128",LLVM 会把这段代码完全向量化——同样的 inner loop 变成一条 v128.load + 一条 v128.add 即可处理 16 个像素。Ch19 会把向量化全过程展开。这里先给一行 punch line:

Add RUSTFLAGS="-C target-feature=+simd128" and LLVM vectorises completely — the inner loop becomes one v128.load + one v128.add processing 16 pixels. Ch19 unfolds the full vectorisation. One-line punchline:

"The Hot Loop" 在后续 22 章的回引地图

Where The Hot Loop returns in the next 22 chapters

一张图看完它的一生

The whole life in one frame

下面是 hot.rs 从源码到屏幕的12 个快照。每一格是这段代码在那一秒的实际面貌——左边五格是"静态形态",中间四格是"编译动作",右边三格是"运行时事件"。读完这张图,你应该能在脑里把后面 Act III/IV/V 的每一章对应回这条主线上。后面 8 个章节(Ch11-Ch19)的顶部都挂了一个 "MAIN-LINE STOP X/12" 胶囊,告诉你"你现在站在哪一格"。

Below: 12 snapshots of hot.rs, from source to pixel. Each cell is what the code actually looks like at that moment — the first five cells are static forms, the middle four are compiler actions, the last three are runtime events. After this image, every chapter in Acts III/IV/V can be slotted back onto this main-line. Eight later chapters (Ch11–Ch19) carry a "MAIN-LINE STOP X/12" capsule at the top telling you "which cell you're standing in".

11 行 Rust,要走 17 道工序
才能在屏幕上动一个像素。 The Hot Loop · main-line

11 lines of Rust, 17 stages,
before one pixel moves on screen. The Hot Loop · main-line

Module 的外壳 — 8 个字节的承诺

The Module shell — a promise in 8 bytes

\0asm + version + 11 段子

\0asm + version + 11 sections

第一字节级别的拆解

Byte-level walkthrough

所有 12 个 section 的 ID

All 12 section IDs

Custom section 是规范留给所有人的逃生舱口——它没有规定的格式,只有一个名字(LEB128 长度 + UTF-8 字节)和任意 payload。DWARF 调试信息、source map、wasm-bindgen 的 JS 胶水都藏在这里。Ch24 会展开 name custom section,它给函数和局部变量起名,让 DevTools 能显示符号。

The Custom section is the spec's escape hatch for everyone — no prescribed format, just a name (LEB128 length + UTF-8 bytes) and arbitrary payload. DWARF debug info, source maps, and wasm-bindgen's JS glue all hide here. Ch24 unpacks the name custom section, which names functions and locals so DevTools can show symbols.

11 段 section — 一个 .wasm 文件的器官学

11 sections — the organology of a .wasm file

每一段都是一个 K-V 仓库

each section is a K-V vault

① Type section · 函数签名表

① Type section · the signature table

问题:"函数 $blur3 长什么样?"
答:"它是 type[0]:(i32 i32 i32 i32) -> ()"——所有 module 内出现的函数签名先注册一遍,后面引用用索引。

Question: "What does $blur3 look like?"
Answer: "It's type[0]: (i32 i32 i32 i32) -> ()" — every signature used in the module is registered up front, later referenced by index.

(type $t0 (func (param i32 i32 i32 i32))) ;; void return implied

为什么把签名独立成表?因为同一个签名会被多个函数共用——主线里只有一个函数,签名表有 1 条。但 Photoshop 的 wasm 里有几十万个函数,只用到几百种签名,共用让 type section 体积小 2~3 个数量级。

Why pull signatures into their own table? Because the same signature is shared among many functions — the main-line has 1 function, so 1 entry. Photoshop's wasm has hundreds of thousands of functions but only hundreds of distinct signatures; sharing collapses the type section by 2–3 orders of magnitude.

② Import section · 来自宿主的函数与对象

② Import section · functions and objects from the host

主线 Hot Loop 没有 import——纯数学函数,不依赖任何 JS API。但下面是 Photoshop 的实际 import section 缩影:

The main-line Hot Loop has no imports — pure math, no JS-side dependency. Below is a snapshot of Photoshop's real import section:

(import "env" "memory"          (memory 256 32768 shared))
(import "env" "__indirect_func_table" (table 4096 funcref))
(import "env" "emscripten_resize_heap" (func (param i32) (result i32)))
(import "wasi_snapshot_preview1" "fd_write" (func (param i32 i32 i32 i32) (result i32)))

四个观察:① 每一条 import 是两段名字 + 一个签名("env" "memory" 是惯例,Emscripten 用 "env" 当 module 名);② memory 可以被 import——这是多线程 wasm 共享内存的关键;③ table 也能 import,允许 JS 给函数指针填值;④ WASI 函数通过 import 引入,在浏览器外的 wasm 里这是主要的"系统调用"通道。

Four notes: ① each import is two-segment name + one signature ("env" "memory" is the Emscripten convention); ② memory itself can be imported — that's the foundation of shared-memory multi-threaded wasm; ③ tables too, letting JS populate function pointers; ④ WASI functions enter via imports, which is the primary "syscall" channel for non-browser wasm.

③ Function section · 函数和签名的连线

③ Function section · wiring functions to their signatures

这一段长得最简洁——就是一个 type index 数组:"函数 0 用 type[0],函数 1 用 type[2],函数 2 用 type[2],..."。函数体本身不在这里,它们在 Code section(0x0a)。把"签名声明"和"函数体"分开是为了流式解码——下载到 function section 就能开始检查 import/export 的类型匹配,不必等 code 段下完。

The plainest section — just an array of type indices: "function 0 is type[0], function 1 is type[2], function 2 is type[2], …". The body lives elsewhere, in the Code section (0x0a). The split between "signature declaration" and "body" exists for streaming decode — once function section is in, you can check import/export type matching without waiting for code.

④ Table section · funcref 的数组

④ Table section · the funcref array

Table 是 wasm 的 "函数指针表",最初是为了 C 函数指针 / C++ vtable / Java 接口分发服务。每个 table 元素是 funcref(MVP)或 externref(2021)。call_indirect 指令用 table 索引 + 类型 ID 调用——类型 ID 必须匹配,否则 trap。Ch09 / Ch11 会展开。

Table is wasm's "function pointer table", born to serve C function pointers / C++ vtables / Java interfaces. Each element is funcref (MVP) or externref (2021). call_indirect uses (table idx + type id) to dispatch — the type id must match or it traps. Expanded in Ch09 / Ch11.

2021 年 reference-types 提案前,一个 module 只能有一张 table。之后可以有多张。主线 Hot Loop 不用 table——它没有间接调用。

Before reference-types (2021), a module could carry only one table. After: multiple. The main-line Hot Loop uses no table — no indirect call.

⑤ Memory section · 线性内存的声明

⑤ Memory section · linear memory declaration

主线声明 (memory 1)——min=1 page=64 KiB,max 不指定。Ch10 完整展开线性内存。

Main-line declares (memory 1) — min=1 page=64 KiB, max unspecified. Ch10 covers linear memory fully.

⑥ Global section · 模块级常量与变量

⑥ Global section · module-level constants and vars

(global $stack_top (mut i32) (i32.const 0x10000))
(global $PI         f64       (f64.const 3.14159265358979))

每个 global 是 (type, mut?, init expr) 三件套。mut 标记可写,initialiser 是一段受限的常量表达式(只能用 iN.const / fN.const / global.get)。Rust / C 的 static 数据如果是常量就来这里,如果是读写就放到 linear memory 的 data section。

Each global is (type, mut?, init expr). mut means writable; initialiser is a constant expression (only iN.const / fN.const / global.get). Rust/C static data lives here when constant; mutable static data goes into linear memory via the data section.

⑦ Export section · 给宿主看的窗口

⑦ Export section · the host-facing window

(export "memory" (memory 0))
(export "blur3"  (func $blur3))
(export "alloc"  (func $alloc))

name → (kind, index) 的字典。kind 可以是 func / table / memory / global / tag(tag 是 exception handling 提案加的)。所有从 JS 调 wasm 的入口都在这里。 JS 那边的 instance.exports.blur3 就是查这张表。

A name → (kind, index) dictionary. Kind ∈ {func, table, memory, global, tag} (tag added by exception handling). Every JS-to-wasm entry point lives here. JS-side instance.exports.blur3 looks up this very table.

⑧ Start section · 模块的 ctor

⑧ Start section · the module's ctor

仅一个数字——某个函数的索引。该函数不能有参数,不能有返回值,在 module instantiate 完成的最后阶段被引擎自动调用。用来做模块级初始化(注册回调、填充常量表)。主线 Hot Loop 没有 start。

Just one number — the index of a function. The start function takes no params, returns nothing, and is invoked automatically by the engine at the end of instantiation. Used for module-level setup (registering callbacks, filling constant tables). Main-line Hot Loop omits start.

⑨ Element section · 给 table 填值

⑨ Element section · table initialisers

语义类似 data section,但写入对象是 table 而非 memory。一个 module 实例化时,element 段把 funcref 们填进对应 table 槽位。C 程序的"函数指针表"就在这里活;C++ 的 vtable 也是。

Semantically similar to data section but writing into tables rather than memory. On instantiation, element segments populate funcref slots. C function pointer tables live here; so do C++ vtables.

⑩ Code section · 字节码本身

⑩ Code section · the bytecode itself

这是最大的一段——主线 Hot Loop 的 code section 占整个文件的 80% 字节。每个函数体的格式是:locals 声明(类型聚合表)+ 表达式序列 + 终止符 0x0b (end)。Ch09 把指令格式撕开。

The biggest section — the Hot Loop's code section is 80% of the entire file. Each function body's format is: locals declaration (run-length encoded by type) + expression sequence + terminator 0x0b (end). Ch09 unpacks the instruction format.

⑪ Data section · 给 memory 填值

⑪ Data section · memory initialisers

把"这段字节请在实例化时写到 linear memory 的某地址"批量声明。C 程序的字符串字面量、Rust 的 static 数组、Emscripten 的 stdlib 数据表都在这里。MVP 时每条数据段必须 active(立即写入);bulk memory 提案(2020)加了 passive 模式,允许 wasm 代码显式调 memory.init 来用——支持代码热更新。

Bulk-declares "at instantiation, write these bytes to memory at address X". C string literals, Rust static arrays, Emscripten's stdlib tables all live here. MVP required every segment to be active (written immediately). The bulk-memory proposal (2020) added passive mode, letting code call memory.init explicitly — supports hot reload.

⑫ DataCount section · 一个事后补丁

⑫ DataCount section · a retroactive patch

2020 年加 bulk memory 后,memory.init segIdx 指令需要在验证时立刻知道 data 段总数。但 code section 在 data section 前面解析——为了不让 validator 反复回扫,设计者插入了一个新 section 0x0c,专门告诉解码器"我有 N 个 data 段"。这是 wasm spec 仅有的"事后补丁"section,反映了流式解析的硬约束。

Bulk memory (2020) made memory.init segIdx need to know the total number of data segments during validation. But code section parses before data — to spare the validator from a back-scan, the designers slipped in a new section 0x0c that just says "I have N data segments". It's the only "retroactive patch" section in the spec, reflecting the hard constraint of streaming parse.

Section 不是设计,是约束的化石。 Field Note · 03

Sections are not design.
They are fossilised constraints. Field Note · 03

类型系统 — 从 4 到 6 再到无限

Type system — from 4 to 6, then to infinity

小到 1 字节,大到任意结构

one byte to arbitrary structure

值类型的全景

All value types at a glance

"函数类型" 也是一种类型

"Function type" is also a type

在 Type section 里出现的 (func (param i32 i32) (result i32)) 用编码 0x60 引导。MVP 时只有 func 这一种"组合类型",GC 提案后加了 0x5F = struct 和 0x5E = array——把 Type section 从"函数签名表"扩成了"组合类型表"。同一段 binary 在 2017 年和 2026 年解析出来的"section 0x01"含义已经悄悄扩张了一倍。

In Type section, (func (param i32 i32) (result i32)) begins with tag 0x60. The MVP had only this one "compound type". The GC proposal added 0x5F = struct and 0x5E = array — quietly stretching Type section from "signature table" to "compound-type table". The same byte (section 0x01) means twice as much in 2026 as in 2017.

类型系统的"缺失":没有 i8/i16/u32

The system's absences: no i8/i16/u32

"为什么 wasm 没有 i8 类型?字符串处理要怎么办?"——这是另一个常见疑问。答案:wasm 的值类型不区分 i8/i16/i32,但内存读写有 i32.load8_u / i32.load8_s / i32.load16_u / i32.load16_s——读 8/16 位 byte,符号或零扩展到 i32。窄类型只存在于 memory 边界,寄存器里永远是 i32 或 i64。

"Why no i8? How do you process strings?" — another perennial question. Answer: wasm's value types don't distinguish i8/i16/i32, but memory access does: i32.load8_u / i32.load8_s / i32.load16_u / i32.load16_s read 8/16-bit bytes and sign- or zero-extend to i32. Narrow types exist only at the memory boundary; in registers, everything is i32 or i64.

同理无符号 vs 有符号区分也只活在指令层面:i32.div_s(signed) vs i32.div_u(unsigned)、i32.lt_s vs i32.lt_u。"类型只标 32/64 位,符号由 op 携带"是 wasm 的核心设计简化——让值类型集合保持小,降低验证器和 JIT 的复杂度。

Same with signed-vs-unsigned: it lives at the opcode layer, not the type layer — i32.div_s vs i32.div_u, i32.lt_s vs i32.lt_u. "Types carry width only; signedness rides on the op" is a core simplification. It keeps the value-type set small and shrinks both validator and JIT.

主线回引 · The Hot Loop 的类型分布

Main-line · types in The Hot Loop

主线 Hot Loop 几乎是 100% i32——这是 wasm 的常态。绝大多数 LLVM 后端在 wasm32 目标上把 usize / size_t 编译成 i32(因为 wasm32 上指针就是 32 位),数组下标也是 i32。f64 主要出现在浮点计算场景,i64 出现在 BigInt 场景。如果你 grep 一个真实 wasm 模块,i32. 开头的 opcode 占 70% ~ 90%。

The main-line is ~100% i32 — wasm's norm. Most LLVM backends compile usize / size_t to i32 on wasm32 (pointers are 32-bit), and array indices are i32. f64 shows up in floating-point math; i64 in BigInt scenarios. Grep any real wasm module and 70–90% of opcodes start with i32.

指令集 — 一字节里的 430 条命令

Opcodes — 430 commands in a single byte

six families, one prefix scheme

six families, one prefix scheme

六大指令家族

Six instruction families

单条指令的拆解

Anatomy of a single instruction

以 i32.load offset=4 align=2 为例。它的字节序列:

Take i32.load offset=4 align=2. Its byte sequence:

三字节里隐藏的设计点:① opcode 是 1 字节,空间精确;② align 是 hint 不是约束——这让 wasm 能跑在 ARM(对齐)和 x86(自由对齐)上无差别;③ offset 是常量,Liftoff 可以 fold 进 [base + reg + 4] 这种寻址模式,免一条 add。三字节里塞了三层信息。

Three bytes hide three design points: ① opcode is one byte, slot-precise; ② align is a hint, not a constraint — letting wasm run on both ARM (aligned) and x86 (free) without changes; ③ offset is constant, so Liftoff folds it into [base + reg + 4] addressing — saving one add. Three bytes, three layers.

主线回引 · The Hot Loop 用到的 6 类 opcode

Main-line · the 6 opcode families in The Hot Loop

49 条指令,49 字节(opcode 部分)+ 立即数(平均 1.2 字节)≈ 110 字节,加上 locals 声明 5 字节、function header 6 字节,凑成约 121 字节的 code section。再加上前面的 6 个 section header 和 export 段,合 192 字节。密度的来源在每一字节都看得见。

49 ops × (1B opcode + ~1.2B imm avg) ≈ 110 bytes, plus 5B locals declaration + 6B function header ≈ 121 bytes of code section. Add six section headers and the export segment: 192 bytes. Density is visible in every byte.

线性内存 — 一片连续的、可越界的、永不 GC 的字节

Linear memory — a flat, bounded, GC-free slab of bytes

64 KiB 一页,最大 4 GiB

64 KiB per page, 4 GiB max

"页" 的几何含义

The geometry of "pages"

为什么是 64 KiB 一页?这数字不是 OS 的 4 KiB / 16 KiB 内存页对齐;它来自一个 i32 寻址 / 2^16 = 2^16 个页 这一计算——4 GiB 总空间 ÷ 2^16 页 = 2^16 = 64 KiB 一页。选 64 KiB 是要在"页粒度太细(grow 太频繁)"和"页太大(浪费)"之间找平衡点,设计者参考了 x86 的 large page 与 ARM 的 64K granule。

Why 64 KiB per page? Not from OS 4 KiB / 16 KiB alignment. It comes from i32 addressing space (4 GiB) ÷ 2^16 pages = 64 KiB per page. The choice balances "too fine-grained (grow too often)" against "too coarse (waste)", referring to x86's large page and ARM's 64K granule.

边界检查 — wasm "safe" 的硬件实现

Bounds checks — the hardware behind wasm's "safe"

每一次 load/store 都必须保证地址在 [0, memory_size) 内,否则 trap。朴素实现:cmp addr, mem_size; ja .trap;——每个内存访问加两条指令,在 inner loop 里 5~10% 开销。

Every load/store must keep its address in [0, memory_size), else trap. Naïve: cmp addr, mem_size; ja .trap; — two extra instructions per access, 5–10% overhead in an inner loop.

现代引擎用一个聪明技巧:把 wasm 的整个 4 GiB 地址空间作为虚拟保留页映射,只把 [0, memory_size) 设为可读写,后面全部设为 PROT_NONE。任何越界访问会触发 SIGSEGV,引擎挂一个 signal handler 把它翻译成 wasm trap。结果是 inner loop 里完全没有显式边界检查,跑得跟 native 几乎一样快——只在 trap 时才慢。

Modern engines use a clever trick: reserve the full 4 GiB virtual address space, mark [0, memory_size) as RW, mark the rest as PROT_NONE. Any overrun raises SIGSEGV, caught by a signal handler that translates it into a wasm trap. The result: zero explicit bounds checks in the hot loop, near-native speed — only slow on actual trap.

主线回引 · The Hot Loop 的内存 layout

Main-line · memory layout of The Hot Loop

; Linear memory after JS-side setup

0x000000 ┌─────────────────────────────────┐
         │ src image data (8 bpp grayscale)│  1920×1080 = 2 073 600 byte
0x1FA400 ├─────────────────────────────────┤
         │ padding ( 4 KiB align )         │
0x1FB000 ├─────────────────────────────────┤
         │ dst image data (output)         │  another 2 073 600 byte
0x3F5400 ├─────────────────────────────────┤
         │ unused                          │  ~ 60 KiB
0x400000 └─────────────────────────────────┘  64 pages (4 MiB)

JS 那边先 mem.grow(63) 把内存扩到 64 page = 4 MiB,然后用 Uint8ClampedArray 视图把 src 图像数据 copy 进去,调 instance.exports.blur3(0, 0x1FB000, 1920, 1080),wasm 函数对 src 做卷积写到 dst,JS 再 new Uint8ClampedArray(mem.buffer, 0x1FB000, len) 取出来显示。整个过程 没有把数据 copy 出 wasm 内存——只是不同 JS 视图共享同一片字节。这是 wasm/JS 协作的"zero copy"模式。

JS first mem.grow(63) to reach 64 pages = 4 MiB, then copies src image bytes in via Uint8ClampedArray, calls instance.exports.blur3(0, 0x1FB000, 1920, 1080), wasm convolves and writes dst, JS reads back via new Uint8ClampedArray(mem.buffer, 0x1FB000, len). The data never leaves wasm memory — different JS views share the same bytes. This is the wasm/JS "zero copy" pattern.

memory.grow 的代价

The cost of memory.grow

grow 是个昂贵指令——它可能触发 ArrayBuffer 重新分配(老 4 MiB 不够时申请新的 16 MiB,copy 整片字节)。grow 后所有 JS 视图 (TypedArray) 立刻被 detached,所有 wasm 那边持有的 base 指针会被引擎自动更新。这条约束让 grow 在 inner loop 里几乎是禁忌,通常只在 module 启动时或者明显边界(图像变大、文件加载)才调用。

grow is expensive — it can trigger a full ArrayBuffer realloc (allocating a fresh 16 MiB when 4 MiB runs short, then copying). After grow, all JS-side TypedArray views are detached immediately; wasm-side base pointers are auto-updated by the engine. The invariant makes grow nearly forbidden inside hot loops — typically called only at startup or coarse boundaries (image resize, file load).

验证 — 一遍线性扫描换来的安全保证

Validation — safety in one linear pass

类型栈的抽象解释

abstract interpretation on a type stack

算法的骨架

The algorithm skeleton

维护两个东西:

Maintain two things:

遍历指令序列,每条指令做三件事:① pop 走它需要的输入类型(类型不对 → fail);② push 它产生的输出类型;③ 如果是控制指令,适当 push/pop cstack。函数末尾 vstack 必须正好等于函数返回类型——否则 fail。就这么简单。但这套机制证明了:任何通过验证的 wasm 不会类型混乱、不会栈溢出、不会未初始化访问。

For each instruction: ① pop the input types it expects (mismatch → fail); ② push the output types it produces; ③ if it's a control op, push/pop cstack accordingly. At function end, vstack must exactly equal the return type — else fail. That's it. Yet this proves any validated wasm cannot suffer type confusion, stack overflow, or uninitialised access.

走一遍 · The Hot Loop 内层 4 行的验证过程

Walk-through · validating 4 inner lines

三种类型错误的具体抓法

Three concrete type errors caught

"多态" 之处:unreachable 之后

The "polymorphic" spot: after unreachable

一个微妙的细节:验证遇到 br(无条件跳转)或 return 或 unreachable 后,后续直到下一个 end 的指令都无法执行到。但代码还在那儿——验证器要怎么处理?答案:把 vstack 标记为 polymorphic stack(假栈),后续 pop 操作都不真的检查,push 也接受任何类型。等遇到 end 或者 else 时再恢复真实栈状态。这一招让验证器即使对"死代码"也能 O(n) 走完。

A subtle detail: after br (unconditional), return, or unreachable, instructions up to the next end are unreachable. But the bytes are still there — what should the validator do? Answer: mark vstack as polymorphic stack — subsequent pops are not really checked, pushes accept any type. Real state restored at the next end or else. This keeps the validator O(n) even through dead code.

并行验证

Parallel validation

单遍验证 + 函数互相独立(只引用 Type / Function / Memory / Table 等"全局"section,这些先解析完)= 函数级并行。V8 的实现给 N 个函数开 min(N, CPU 核数) 个验证 worker,每个 worker 拿一个函数独立验。Photoshop 那种 30 万函数的 wasm 模块,在 8 核机器上 ~500 ms 就能验完——这是为什么 wasm 启动比想象中快。

Single-pass validation + function independence (functions reference only the "global" sections — Type / Function / Memory / Table — already parsed) = function-level parallelism. V8 spawns min(N, num_cpus) workers and each takes one function. Photoshop's 300 K-function wasm validates in ~500 ms on an 8-core box — which is why wasm startup is faster than people expect.

验证不是检查代码,
是把代码读成一个可证明的形状。 Field Note · 03

Validation isn't checking code.
It is reading code into a provable shape. Field Note · 03

Decode — 边下载边解码的字节流

Decode — bytes parsed as they arrive

streaming compilation

streaming compilation

JS 那端的两种调用方式

Two JS-side call patterns

// 慢路径(non-streaming):先 ArrayBuffer 再 compile
const buf = await fetch('hot.wasm').then(r => r.arrayBuffer());
const mod = await WebAssembly.compile(buf);  // 等下完才开始

// 快路径(streaming):fetch 进来一段就开始编
const mod = await WebAssembly.compileStreaming(fetch('hot.wasm'));

compileStreaming 需要 server 回 Content-Type: application/wasm——否则会 fallback 到 buffer 路径并 throw 一个警告。这是常见踩坑(把 .wasm 当 .bin 上 CDN 时 MIME 不对)。

compileStreaming requires the server to return Content-Type: application/wasm — else it falls back to the buffer path and emits a warning. A common pitfall when serving .wasm as .bin from a CDN.

decoder 的状态机

Decoder state machine

// V8 ModuleDecoder 简化状态机

[kPreamble]      ; expecting magic + version (8 bytes)
       ├─▶ kSectionHeader   ; expecting id byte + LEB128 length
              ├─▶ kTypeSection     ; 0x01 · vec[Type]
              ├─▶ kImportSection   ; 0x02 · vec[Import]
              ├─▶ kFunctionSection ; 0x03 · vec[u32 type-idx]
              ├─▶ kTableSection    ; 0x04
              ├─▶ kMemorySection   ; 0x05
              ├─▶ kGlobalSection   ; 0x06
              ├─▶ kExportSection   ; 0x07
              ├─▶ kStartSection    ; 0x08
              ├─▶ kElementSection  ; 0x09
              ├─▶ kCodeSection     ; 0x0a · 进入 per-function loop
              │       └─▶ for each function:
              │             1. parse body bytes
              │             2. enqueue to validator worker
              │             3. enqueue to Liftoff worker
              ├─▶ kDataSection     ; 0x0b
              └─▶ kCustomSection   ; 0x00 · name / dwarf / vendor

每个状态对应一个 section 的解析函数,内部都是同一种结构:先读 LEB128 数量,再 for 循环依次解析每个 entry。这种规则化让 decoder 简单到可以单文件 (module-decoder.cc) 几千行写完。

Each state maps to a parsing function for one section, all sharing the same shape: read LEB128 count, then for-loop entries. The regularity keeps the decoder small — one file (module-decoder.cc), a few thousand lines.

流式 + 并行的时间线

Streaming + parallel timeline

code section 的"函数体偏移表"

The "function-body offset table" trick

code section 的格式有一个细节让流式编译变得可行:每个函数体前面都有一个 LEB128 长度。这让 decoder 不必先扫一遍找边界,可以直接 fread 长度 → fread 函数体 → 入队 → fread 下一段长度。"self-describing 长度前缀" 是 wasm 设计里反复出现的母题——module 长度、section 长度、函数体长度、import name 长度,全是 LEB128 前缀。

A detail in the code section makes streaming feasible: each function body is prefixed by a LEB128 length. The decoder doesn't need a pre-scan — just read length → read body → enqueue → next length. "Self-describing length prefix" is a recurring motif — module length, section length, body length, import-name length, all LEB128-prefixed.

Validate — 函数级并行的形状证明

Validate — function-level parallelism, proven by shape

N 个函数,N 个 worker

N functions, N workers

为什么函数级并行可行

Why function-level parallel works

关键前提是函数体只引用模块级声明(type / function / table / memory / global / element),这些都在 code section 之前的 section 里解析完了。函数 A 验证时不需要看函数 B——它最多通过 call 引用 B 的签名(已知)。所以 N 个 worker 可以独立验证 N 个函数,彼此不通信。

The key invariant: function bodies reference only module-level declarations (type / function / table / memory / global / element), all parsed before the code section. Function A's validator doesn't need to look at function B — at most it sees B's signature via call (already known). So N workers validate N functions independently, no inter-thread comms.

早失败 vs 晚失败

Fail-fast vs fail-late

如果第 3 个函数验证失败,后面 1000 个函数还要不要继续验证?V8 选择继续——所有 worker 把活做完,最后聚合错误。这听起来浪费,但因为 worker 是并行的,继续做不会延后失败时间;反而提前 abort 需要协调(kill 其他 worker),代码复杂度反而高。"并行算法里 fail-fast 不一定快"是 V8 设计里反复出现的取舍。

If function 3 fails, do the remaining 1000 keep validating? V8 says yes — let all workers finish, aggregate errors at the end. Sounds wasteful, but because workers run in parallel, continuing doesn't delay failure; aborting would need coordination (kill other workers), with higher code complexity. "Fail-fast isn't necessarily fast in a parallel pipeline" — a trade-off V8 makes repeatedly.

主线回引 · The Hot Loop 的验证时间

Main-line · Hot Loop validation time

主线只有 1 个函数,所以"并行"在这里退化成单 worker。49 条指令,vstack 最深 4 槽,cstack 最深 2 frame,在 M1 Pro 上验证耗时 ~ 6 µs。这一数字给你一个数量级感受:验证比解码还快,因为验证不分配内存(用栈上小固定容量数组就够了)。

The main-line has 1 function, so "parallel" degenerates to single worker. 49 ops, vstack max depth 4, cstack max depth 2 — on M1 Pro, validation takes ~ 6 µs. The order of magnitude: validation is faster than decoding, because it allocates nothing — a small fixed-cap stack array suffices.

Liftoff — 单遍出码的"不优化但快"基线 JIT

Liftoff — the "unoptimised but instant" baseline JIT

10 MB/s · 0 IR · 0 register alloc

10 MB/s · 0 IR · 0 register alloc

Liftoff 的两个"狠"

Two ruthless choices Liftoff makes

主线 · Liftoff 对 The Hot Loop 出的码(完整版)

Main-line · Liftoff's output for The Hot Loop (full)

; blur3 -- Liftoff codegen (x86-64, simplified)
0x000000 push   rbp
0x000001 mov    rbp, rsp
0x000004 sub    rsp, 0x40                ; 8 stack slots
0x000008 mov    [rbp-0x08], rdi          ; spill $src
0x00000c mov    [rbp-0x10], rsi          ; spill $dst
0x000010 mov    [rbp-0x18], edx          ; spill $w
0x000014 mov    [rbp-0x1c], ecx          ; spill $h

; outer loop: y = 1
0x000018 mov    dword ptr [rbp-0x20], 1  ; $y = 1
0x000020 mov    eax, [rbp-0x1c]
0x000024 dec    eax                      ; eax = h - 1
0x000026 cmp    [rbp-0x20], eax
0x000029 jge    .end_y

.loop_y:
; inner loop: x = 1
0x00002b mov    dword ptr [rbp-0x24], 1  ; $x = 1
0x000033 mov    eax, [rbp-0x18]
0x000037 dec    eax                      ; eax = w - 1
0x000039 cmp    [rbp-0x24], eax
0x00003c jge    .end_x

.loop_x:
; sum = 0
0x00003e mov    dword ptr [rbp-0x28], 0

; 9 byte loads, 8 adds — Liftoff emits each one
0x000046 mov    rax, [rbp-0x08]          ; $src
0x00004a movzx  edx, byte ptr [r15+rax]  ; i32.load8_u offset=0 (r15 = mem base)
0x00004e add    [rbp-0x28], edx          ; sum += byte

0x000051 mov    rax, [rbp-0x08]          ; reload $src ← spill cost
0x000055 movzx  edx, byte ptr [r15+rax+1]
0x00005a add    [rbp-0x28], edx
...
; (similar 7 more times — Liftoff makes no attempt to hoist $src)
...

; sum / 9 — Liftoff does NOT do magic-number multiplication
0x0000c0 mov    eax, [rbp-0x28]
0x0000c3 xor    edx, edx
0x0000c5 mov    ecx, 9
0x0000ca div    ecx                      ; expensive! ~25 cycles

; store dst[y*w + x]
0x0000cc ...
0x0000e0 mov    byte ptr [r15+rbx], al

; x++; loop_x
0x0000e4 inc    dword ptr [rbp-0x24]
0x0000e8 jmp    .loop_x
...
.end_x:
.end_y:
0x000130 leave
0x000131 ret

这段~ 240 字节的 x86-64 代码就是 Liftoff 对 hot.wasm 的输出。三个观察:① $src 在每次 load 前都重新从 [rbp-0x08] 加载——Liftoff 不知道也不分析 "这个值我刚加载过";② sum / 9 用了真 div 指令,~25 cycle;③ 函数体没有 SIMD 化。但出码时间在 200 µs 量级——这正是它要的。

~240 bytes of x86-64 is Liftoff's output for hot.wasm. Three notes: ① $src is reloaded from [rbp-0x08] before every load — Liftoff doesn't know it just loaded this; ② sum / 9 uses a real div, ~25 cycles; ③ no SIMD. But codegen time is ~200 µs — exactly the target.

Tier-up 触发机制

The tier-up trigger

每个 Liftoff 函数入口都塞一个计数器:

Every Liftoff function prologue carries a counter:

cmp    dword ptr [r13+0x40], 0x100      ; tier-up threshold = 256 calls
jne    +0x4
call   WasmCompileLazy                  ; → schedule TurboFan recompile

2 条指令的开销,每次进入函数加 1 次 cmp + 1 次 jne(不跳转)。达到阈值时调用 WasmCompileLazy,把这个函数入队到 TurboFan 后台 worker——不阻塞当前调用,Liftoff 版继续跑。后台 worker 编完后,引擎用一个 atomic store 把函数地址表里的入口换成 TurboFan 版,下次调用就走 TurboFan。

Two-instruction overhead: one cmp + one jne (not taken) per entry. At threshold, call WasmCompileLazy to enqueue the function for a background TurboFan worker — does not block the current call, Liftoff version keeps running. After the worker finishes, an atomic store swaps the function-table entry to point to the TurboFan version; the next call goes to TurboFan.

TurboFan — sea-of-nodes 把它优化成接近 native

TurboFan — sea-of-nodes lifts it to near-native

2 ms 出码,80% of native

2 ms emit, 80% of native

从字节到机器码的 6 步

Six steps from bytes to machine code

主线 · TurboFan 出码 vs Liftoff 出码

Main-line · TurboFan output vs Liftoff output

TurboFan 编译耗时 10× 于 Liftoff,但出码运行快 ~ 3× 于 Liftoff。关键洞察是这两个数字不矛盾——TurboFan 在后台编,运行时把"编译延迟"摊到了后台 worker。用户看到的延迟是"Liftoff 编译完+第一次跑",TurboFan 是后面"悄悄变快"的。这是 wasm tiering 的全部哲学。

TurboFan compiles 10× slower than Liftoff, but the resulting code runs ~3× faster. The crucial insight: these don't conflict — TurboFan compiles in the background, amortising its latency onto a worker. Perceived latency is "Liftoff done + first run"; TurboFan is the "silent" speedup later. That's wasm tiering in one sentence.

从 TurboFan 到 Turboshaft

From TurboFan to Turboshaft

2022 年 V8 团队启动 Turboshaft 项目,目标是替换 TurboFan。原 TurboFan 的 sea-of-nodes 在内存里是图结构,每次访问要解引用,在大模块上 cache miss 严重。Turboshaft 改成线性 IR 序列(类似 LLVM 的 BB instructions),内存连续,优化 pass 速度上升 30~50%。2023 年起 V8 wasm 默认走 Turboshaft,但 IR 和 pass 集合跟 TurboFan 高度兼容,从外部看几乎无感。

In 2022 the V8 team began Turboshaft, with the goal of replacing TurboFan. The original TurboFan keeps its sea-of-nodes as an in-memory graph; every access dereferences, and on large modules cache misses dominate. Turboshaft uses a linear IR sequence (like LLVM BB instructions), so memory is contiguous and pass speed improves 30–50%. Since 2023, V8 wasm has run Turboshaft by default, but IR and pass set are highly TurboFan-compatible — externally near-invisible.

Instantiate — Module 是模板,Instance 是身体

Instantiate — module is the template, instance is the body

memory · table · globals · imports · start

memory · table · globals · imports · start

实例化的 7 步

Seven steps of instantiation

JS 那一面的代码

JS-side code

const importObject = {
  env: {
    memory: new WebAssembly.Memory({ initial: 64, maximum: 256 }),
    log:    (x) => console.log('wasm says', x),
  },
  wasi_snapshot_preview1: { /* WASI shims */ },
};

const { module, instance } = await WebAssembly.instantiateStreaming(
  fetch('hot.wasm'),
  importObject
);

instance.exports.blur3(srcPtr, dstPtr, 1920, 1080);

"多 Instance · 单 Module" 的用法

"Many instances · one module" pattern

Web Worker + SharedArrayBuffer 场景里,常见做法是主线程 compile 一次 Module,所有 worker 都用同一个 Module 创建独立 Instance。每个 worker 有自己的 memory(可能是 import 来的共享 memory),共享代码、不共享栈。Photoshop / Figma 都这样做。编译只跑一次,内存按需复制。

With Web Workers + SharedArrayBuffer, the standard pattern is: main thread compiles the Module once; each worker creates its own Instance from the same Module. Each worker has its own memory (possibly imported shared memory), sharing code but not stacks. Photoshop and Figma both do this. Compile once, memory on demand.

JS ↔ Wasm — 看不见的 trampoline 与 5 ns 的代价

JS ↔ Wasm — invisible trampolines and the 5 ns toll

两条 ABI 中间的桥

the bridge between two ABIs

4 类 trampoline

Four trampoline kinds

JS-to-Wasm wrapper 都做了什么

What the JS-to-Wasm wrapper does

; JS-to-Wasm wrapper for blur3(src, dst, w, h)
push   rbp
mov    rbp, rsp

; arg 0 (src): expect SMI, unbox to i32
mov    rax, [rdi+0x10]          ; rdi = first arg, JS heap pointer
test   rax, 0x1                 ; SMI test (low bit = 0 means SMI in V8)
jnz    .slow_path                ; HeapNumber path
sar    rax, 1                   ; SMI shift to get raw int
mov    edi, eax                 ; load into wasm arg reg
...                              ; same for args 1..3

; setup wasm frame
mov    r15, [r13+0x20]          ; load wasm memory base
mov    r14, [r13+0x28]          ; load wasm instance pointer

; tail-call into wasm function
jmp    [r14+0x40]               ; → Liftoff/TurboFan-compiled blur3

.slow_path:
call   ConvertNumberToInt32     ; handles HeapNumber, BigInt, throws on NaN
jmp    back

观察:① 主路径是纯寄存器操作 + 一条 jmp,~5 ns;② SMI 解包是一条 test + sar,几乎免费;③ 慢路径处理 HeapNumber/BigInt/NaN,大约 50~100 ns;④ r15(memory base)和 r14(instance)被显式 load——wasm 函数运行时假设这两个寄存器有效。

Notes: ① fast path is pure register ops + one jmp ≈ 5 ns; ② SMI unboxing is one test + sar, practically free; ③ slow path (HeapNumber / BigInt / NaN) is ~50–100 ns; ④ r15 (memory base) and r14 (instance) are explicitly loaded — the wasm body assumes these registers hold valid values.

Wasm-to-JS 的更贵代价

The pricier Wasm-to-JS direction

反方向更贵:wasm 调用 JS 函数(比如 console.log)需要构造 JS call frame、把 i32 boxing 成 SMI、检查 receiver、可能 GC——单次大概 100~300 ns。"wasm 频繁调 DOM" 是性能反模式——每次过桥的成本就吃掉了算术速度的优势。Photoshop 的策略是把整张图片 copy 到 linear memory,处理完一整张再过桥回 JS,把过桥次数压到极少。

The reverse is pricier: wasm calling JS (e.g. console.log) constructs a JS call frame, boxes i32 to SMI, checks the receiver, possibly triggers GC — ~100–300 ns per call. "Frequent DOM calls from wasm" is the canonical perf anti-pattern — boundary cost devours arithmetic speedup. Photoshop's strategy: copy the entire image into linear memory, process the whole thing, cross the boundary once on return. Minimise crossings.

主线 · The Hot Loop 的过桥成本

Main-line · the Hot Loop crossing cost

2017 MVP 时,JS 调 wasm 单次成本 ~ 80 ns——这意味着每秒最多 1200 万次过桥,对 60 fps 的游戏来说是真实瓶颈。V8 后续 5 年逐步优化:把 wrapper 做成 builtin、把 SMI 解包内联、用 call-ref 替代 call-indirect 间接调用、最后是 2025 年的直接调用——把 wrapper 完全 elide,JS 编译器看穿"这次 call 一定调 wasm" 时直接 emit 一条 call。如今边界几乎免费。

In the 2017 MVP, JS-calling-wasm cost ~80 ns per call — a hard cap of 12 M crossings/s, a real bottleneck for 60 fps games. V8 optimised over five years: turn wrappers into builtins, inline SMI unboxing, replace call-indirect with call-ref, and finally the 2025 direct call — elide the wrapper entirely, JS compiler sees "this call definitely lands in wasm" and emits a plain call. Today the boundary is nearly free.

最贵的指令不是除法,是过边界。 Field Note · 03

The most expensive instruction is not division.
It is crossing the boundary. Field Note · 03

Threads — 共享内存进沙箱

Threads — shared memory inside the sandbox

SharedArrayBuffer · atomics · futex

SharedArrayBuffer · atomics · futex

三种新指令

Three new instruction families

JS 那一面的 setup

JS-side setup

// Main thread
const mem = new WebAssembly.Memory({
  initial: 256, maximum: 2048, shared: true    // ← key flag
});
const buf = mem.buffer;  // instanceof SharedArrayBuffer

const workers = [...Array(8)].map(() => new Worker('worker.js'));
workers.forEach(w => w.postMessage({ mem }));    // share Memory across workers

// worker.js
self.onmessage = async ({ data }) => {
  const { instance } = await WebAssembly.instantiateStreaming(
    fetch('hot.wasm'),
    { env: { memory: data.mem } }                // import same Memory
  );
  instance.exports.blur3_threaded(srcPtr, dstPtr, w, h, workerId);
};

五件事:① shared: true 让 ArrayBuffer 变成 SharedArrayBuffer——浏览器对此要 Cross-Origin-Isolated 才允许;② maximum 必填——因为 grow shared memory 在 JS 那边复杂(所有 worker 都要被通知),所以提前占好上限;③ 主线程 compile 一次 Module,所有 worker 复用;④ 每个 worker 创建自己的 Instance,但 import 同一个 Memory——这是共享内存的关键;⑤ wasm 那边 thread id 通过函数参数显式传入,不是隐式。

Five things: ① shared: true upgrades the ArrayBuffer to SharedArrayBuffer — browsers require Cross-Origin-Isolated for it; ② maximum is mandatory — growing shared memory cross-worker is complex, so the ceiling is fixed up front; ③ main thread compiles the Module once, all workers reuse it; ④ each worker spawns its own Instance but imports the same Memory — that's the shared-memory bridge; ⑤ thread id is passed explicitly as a function arg, not implicit.

Spectre 在这里的故事

The Spectre side-story

2018 年 1 月 Spectre 漏洞披露后,所有浏览器立刻关闭了 SharedArrayBuffer——因为高分辨率定时器 + 共享内存 = 可以利用 cache 旁路通道。wasm threads 当时 phase 3 即将 ship,被推迟了一年半。最终方案:要求页面声明 Cross-Origin-Embedder-Policy: require-corp + Cross-Origin-Opener-Policy: same-origin——把进程隔离到只跟自己同源的脚本一起跑,这样旁路通道泄漏只会泄漏自己的数据,无意义。2021 年起浏览器在 COOP+COEP 头下重新启用 SharedArrayBuffer。如今你能在 Figma 上跑 wasm threads,就是因为它服务端正确设置了这两个头。

When Spectre dropped in January 2018, browsers immediately disabled SharedArrayBuffer — high-res timers + shared memory = a usable cache side-channel. wasm threads, then at phase 3 and almost shipping, slipped a year and a half. The eventual mitigation: require pages to declare Cross-Origin-Embedder-Policy: require-corp + Cross-Origin-Opener-Policy: same-origin — isolate the process so it only co-resides with same-origin scripts; any side-channel leak only leaks your own data, which is harmless. From 2021, browsers re-enabled SharedArrayBuffer behind COOP+COEP. You can run wasm threads on Figma because they set those headers correctly.

主线 · The Hot Loop 多线程版的提速

Main-line · The Hot Loop, threaded

8 个 worker 把图像分成 8 个水平条带,每个 worker 独立处理。理想线性加速 8×,实测 5.8×——剩下 28% 损失在 worker 启动开销、worker 间内存通信、最后聚合点同步。这已经是 wasm 在 web 平台能做到的"多核计算"上限。

Eight workers slice the image into eight horizontal stripes, each processed independently. Ideal linear speedup is 8×; measured 5.8×. The remaining 28% goes to worker startup, cross-worker memory contention, and the final sync barrier. This is the practical ceiling for "multi-core computation" on the web platform today.

SIMD — 16 字节寄存器里的 16 个像素

SIMD — 16 pixels in a 16-byte register

v128 · lane ops · 6× speedup

v128 · lane ops · 6× speedup

v128 是个"多义类型"

v128 is a "polysemic type"

128 bit 可以看成:

128 bits can be viewed as:

同一个 v128 寄存器,根据操作解释成不同 lane shape。i8x16.add 是 16 个 8-bit 整数对应相加,f32x4.mul 是 4 个 32-bit 浮点对应相乘。类型在指令里,不在值里——这是 wasm 整个类型系统的复制粘贴(回顾 Ch08)。

A single v128 register is reinterpreted by the op's lane shape. i8x16.add = 16 paired 8-bit adds; f32x4.mul = 4 paired 32-bit float mults. The type lives in the op, not the value — a copy-paste from wasm's overall design (recall Ch08).

主线 · The Hot Loop 的 SIMD 版本

Main-line · the SIMD version of The Hot Loop

;; SIMD-vectorised inner loop: process 16 columns at once

v128.load offset=0      ;; 16 bytes from src row 0
v128.load offset=1      ;; 16 bytes shifted right by 1
i16x8.extadd_pairwise_i8x16_u  ;; widen + add pairs → 8 × i16
v128.load offset=2      ;; 3rd column
i16x8.extadd_pairwise_i8x16_u
i16x8.add                ;; sum 3 columns of row 0
;; ... repeat for rows 1 and 2, then sum 3 rows → 8 × i16 sums ...
i16x8.div_u              ;; ÷ 9 (one v128 op = 8 div in 4 cy)
i8x16.narrow_i16x8_u      ;; saturate back to 8-bit
v128.store offset=0     ;; 16 bytes written to dst

一次循环处理 16 个像素,而不是一个。3×3 卷积变成"3 行 SIMD 加法 + 1 次 SIMD 除法 + 1 次 SIMD 写入"。TurboFan 把这段 wasm 翻成 x86 的 PADDW / PMULHRSW / PSRLW 等 SSE2 指令——每条 inner loop 大约 18 条 SSE 指令,处理 16 像素,平均每像素 ~1.1 条 SSE。这比标量版本(每像素 ~20 条 x86 指令)快 6 倍以上,正是 hero pulse bar 里看到的 6.8× 来源。

One iteration handles 16 pixels, not one. The 3×3 convolution becomes "3 rows of SIMD add + 1 SIMD divide + 1 SIMD store". TurboFan lowers this wasm into x86 PADDW / PMULHRSW / PSRLW SSE2 ops — ~18 SSE instructions per inner iteration handling 16 pixels, averaging ~1.1 SSE per pixel. Vs ~20 x86 instructions per pixel in the scalar version → 6×+ speedup, exactly the 6.8× from the hero pulse bar.

wasm-GC — 终于,wasm 有了自己的对象

wasm-GC — at last, wasm has its own objects

struct · array · i31 · ref

struct · array · i31 · ref

新增的类型与指令

New types and instructions

(type $Point (struct (field $x f64) (field $y f64)))
(type $Vec   (array (mut i32)))

;; allocate
struct.new $Point   ;; (consume 2 f64 on stack → produce (ref $Point))
array.new  $Vec     ;; (i32 len + i32 init → produce (ref $Vec))

;; access
struct.get $Point $x   ;; pop ref, push f64
array.get_u $Vec      ;; pop ref + i32 idx, push elem

;; cast (downcast)
ref.cast (ref $Point)   ;; runtime check, trap on mismatch

;; small ints inline (avoid heap alloc)
i31.new             ;; pop i32 (31-bit limited), push i31ref
i31.get_s           ;; unbox

三个观察:① 类型用名义定义($Point 不等于另一个 same-shape struct),允许 sub-typing;② 引用类型可以为 null 也可以 nullable;③ i31ref 直接借用 V8 的 SMI 技术——31 位整数不分配堆,直接 inline 到 ref 槽位低位,跟 JS 的 Number 互操作几乎免费。

Three notes: ① types are defined nominally (one $Point ≠ another struct of the same shape) and support sub-typing; ② references can be nullable or not; ③ i31ref borrows V8's SMI trick — 31-bit ints are not heap-allocated, inlined into the low bits of a ref slot, near-free interop with JS Number.

为什么不直接共享 JS 的对象

Why not just share JS objects?

"wasm 跑在 V8 上,直接用 JS Object 不就行了?"——这是另一个常见疑问。答案:JS Object 是动态形状的(隐藏类、IC、加 property 时形状变),wasm 需要静态形状的对象才能做高效 codegen。wasm-GC 的 struct 类型在编译期固定 layout——访问 $Point.$x 就是 mov reg, [ref+8],一条指令,没有 IC,没有 deopt。共享 GC 不等于共享对象模型。

"Wasm runs on V8 — why not use JS Object directly?" — another common question. Answer: JS Object is dynamically shaped (hidden classes, ICs, shape changes on property add), but wasm needs statically shaped objects for efficient codegen. A wasm-GC struct has a layout fixed at compile time — accessing $Point.$x compiles to mov reg, [ref+8], one instruction, no IC, no deopt. Sharing the GC ≠ sharing the object model.

Component Model — 跨语言的 ABI

Component Model — a cross-language ABI

WIT · interface types · WASI 0.2

WIT · interface types · WASI 0.2

WIT — 接口描述语言

WIT — the IDL

// blur.wit — the interface for our image-processor component

package ursb:image@0.1.0;

interface filter {
    record bitmap {
        width:  u32,
        height: u32,
        pixels: list<u8>,
    }

    enum error { invalid-size, oom }

    blur3: func(input: bitmap) -> result<bitmap, error>;
}

world image-tools {
    export filter;
}

用 wit-bindgen 工具:

Use wit-bindgen:

$ wit-bindgen rust blur.wit --out-dir ./bindings/
# Generates Rust types matching the WIT — `Bitmap { width: u32, ... }` plus a trait you `impl`

$ wit-bindgen go blur.wit --out-dir ./bindings/
# Same component, now in Go

$ wasm-tools component new core.wasm -o blur.component.wasm
# Package the core module + component metadata

每种语言的 binding generator 知道怎么把它的原生类型 marshal 进 ABI 形式:Rust 的 String → (ptr, len),Go 的 string → (ptr, len) 但用 GC 跟踪,Java 的 String → UTF-8 编码后传递。所有这些细节对组件作者完全透明。

Each binding generator knows how to marshal native types into the ABI: Rust's String → (ptr, len), Go's string → (ptr, len) tracked by GC, Java's String → UTF-8-encoded. All these details are invisible to the component author.

为什么这件事这么重要

Why this matters so much

WASI 0.2(2024 ship)的所有"系统接口" —— wasi:io / wasi:filesystem / wasi:http / wasi:clocks —— 都用 Component Model 声明。这意味着同一个 wasm 组件 可以在 Wasmtime / Wasmer / Spin / Jco / 浏览器 polyfill 上跑,只要 host 提供对应的 WASI 接口实现。这是真正的"一次编译,处处运行"——比 Java 当年的承诺更彻底,因为它跨语言。Cloudflare Workers, Fastly Compute@Edge, Shopify Functions, Spin 等"边缘计算 wasm" 平台,本质都是 Component Model 的客户。

WASI 0.2 (shipped 2024) declares all its "system interfaces" — wasi:io / wasi:filesystem / wasi:http / wasi:clocks — through the Component Model. That means one wasm component runs on Wasmtime / Wasmer / Spin / Jco / a browser polyfill, as long as the host implements the matching WASI interface. The real "compile once, run anywhere" — more thorough than Java's old promise because it's cross-language. Cloudflare Workers, Fastly Compute@Edge, Shopify Functions, Spin — every edge-wasm platform is essentially a Component Model customer.

还有六个提案 — 排队中的扩张

Six more — proposals in the queue

tail-call · EH · memory64 · JSPI · stack-switching · multi-memory

tail-call · EH · memory64 · JSPI · stack-switching · multi-memory

tail-call 的具体效果

What tail-call concretely enables

;; before — call + return: stack grows N deep for N tail calls
(func $fact (param $n i32) (param $acc i32) (result i32)
  local.get $n
  i32.eqz
  (if (result i32) (then local.get $acc)
    (else
      local.get $n i32.const 1 i32.sub
      local.get $n local.get $acc i32.mul
      call $fact   ;; ← regular call, stack grows N frames
)))

;; after — return_call: reuse current frame, stack stays at 1 frame
      return_call $fact   ;; ← O(1) stack

没有 tail-call 时,函数式语言只能用 trampoline 模拟尾递归——把 "下一步要调用什么" 当返回值,外层循环里轮询。代码丑、慢 3 倍。tail-call ship 之后 Scheme / Erlang / OCaml 编译到 wasm 才真正可用。

Without tail-call, functional languages had to simulate tail recursion via trampolines — returning "what to call next" and looping in an outer loop. Ugly, 3× slower. Post-tail-call, Scheme / Erlang / OCaml-to-wasm is genuinely usable.

JSPI 解决了什么

What JSPI fixes

假设你的 wasm 要 fetch 一个网络资源。在 MVP 里你只能:① wasm 调用一个 JS 函数,JS 起 fetch,等 fetch 完后回调 wasm 的另一个函数。代码丑,因为 wasm 函数被切成两半。JSPI 让 wasm 函数能停在中间,等 JS Promise resolved 再继续。引擎在 stack 上记一个 continuation,fetch 完后从这个 continuation 恢复。对开发者像是同步代码,引擎在底下做了异步。

Suppose your wasm wants to fetch a network resource. In the MVP, you could only: ① wasm calls a JS function, JS issues fetch, on completion JS calls back another wasm function. Ugly — your wasm function is cut in half. JSPI lets a wasm function pause mid-execution, await a JS Promise, resume. The engine stores a continuation on the stack; on resolve, it resumes from that continuation. To the developer it reads as sync code; under the hood the engine does async.

性能模型 — wasm 为什么(有时)快,为什么(有时)不

Performance model — why wasm is fast (and sometimes isn't)

把工程经验写成公式

turning engineering folklore into a formula

三种场景的具体数字

Three scenarios, concrete numbers

"wasm 慢启动" 的误解

The "wasm has slow startup" myth

人们以为 wasm 启动慢——其实Liftoff 让 wasm 启动比 JS 还快。一个 1 MB 的 wasm 模块,Liftoff ~ 100 ms 出码就能跑;一个 1 MB 的 minified JS,V8 要 parse + Ignition + 进 inline cache,~ 200 ms 才稳定。wasm 启动从 2018 年起就不再是性能问题。剩下的延迟主要是下载——文件大小决定的,不是 wasm 的错。

People assume wasm startup is slow — actually Liftoff makes wasm boot faster than JS. A 1 MB wasm module: Liftoff ~100 ms to runnable. A 1 MB minified JS: V8 parses + Ignition + IC warmup ~200 ms to steady state. Since 2018, wasm startup hasn't been a perf problem. Remaining latency is download — a function of file size, not wasm's fault.

三个反直觉

Three counter-intuitive findings

DevTools 调试 — DWARF 把符号还给字节

DevTools debugging — DWARF returns names to bytes

name section · source maps · DWARF

name section · source maps · DWARF

三层的对比

The three layers compared

Chrome DevTools 启用 wasm 调试

Enabling wasm debug in Chrome DevTools

2020 年 Chrome 88 起,DevTools 集成了 wasm 调试器(由 Google 内部 chrome-devtools-frontend 团队和 Bloomberg 合作开发)。开启步骤:

From Chrome 88 (2020), DevTools includes a wasm debugger (built by Chromium's chrome-devtools-frontend team and Bloomberg). Enable in three steps:

能做什么 · 调试体验

What you can do · debug UX

现实战场 — wasm 在工业级产品里的样子

Real-world battlefields — wasm in production at scale

Figma · Photoshop · AutoCAD · Ruffle · ffmpeg

Figma · Photoshop · AutoCAD · Ruffle · ffmpeg

Figma — 第一个 web wasm 真实成功故事

Figma — the first true wasm-on-web success

Figma 2016 年上线时,渲染引擎已经是 C++ 编到 asm.js 跑在浏览器里。2017 年 wasm MVP ship 后立刻迁移到 wasm——启动速度提升 3 倍,文件加载提升 2 倍。Evan Wallace(Figma 联合创始人)在博客里写过:"without WebAssembly, Figma would not exist"。Figma 的整个矢量编辑、 canvas 渲染、协作 OT 算法都在 wasm 里——只有 UI 是 React。它定义了"wasm-first 应用" 的工程模板。

Figma launched in 2016 with its rendering engine already compiled from C++ to asm.js. Post-wasm MVP in 2017 it migrated immediately — 3× startup speedup, 2× file load. Co-founder Evan Wallace wrote on the blog: "without WebAssembly, Figma would not exist". Figma's vector editing, canvas rendering, and collaborative OT all run inside wasm — only the UI is React. It defined the engineering template for "wasm-first apps".

Photoshop Web — 30 万行 C++ 的搬运

Photoshop Web — porting 300 K lines of C++

2023 年 Adobe 把 Photoshop 的 pixel pipeline 编译到 wasm,在 Chromium 上开始公测。模块大小:70 MB(gzip 后 18 MB)。用了 wasm threads + SIMD + 多 memory + JSPI。其中最大的工程难点是 Photoshop 自带的内存分配器(jemalloc)要从假定有 mmap 的 native 环境改为 wasm 的 linear memory——他们花了 9 个月把 jemalloc 移植成"wasm 友好" 的版本。Photoshop Web 是目前为止编到 wasm 的最大商业代码库。

In 2023 Adobe compiled Photoshop's pixel pipeline to wasm and opened public beta on Chromium. Module size: 70 MB (18 MB gzipped). Uses wasm threads + SIMD + multi-memory + JSPI. The hardest engineering hurdle was porting Photoshop's bundled allocator (jemalloc) from a mmap-assuming native world to wasm's linear memory — 9 months to produce a "wasm-friendly" jemalloc. Photoshop Web is the largest commercial codebase ever compiled to wasm.

AutoCAD Web — 30M LOC, 35 年历史

AutoCAD Web — 30 M LOC, 35-year history

AutoCAD 1982 年首次发布,代码累计 30M+ LOC。Autodesk 2018 年开始把它编到 wasm,2020 年正式上线 AutoCAD Web App。移植中最大的挑战不是计算速度,是文件 IO 路径——AutoCAD 假定有本地文件系统,wasm 在浏览器里没有,要用 OPFS(Origin Private File System)和 fetch API 模拟。这是WASI 0.2 的 wasi:filesystem 在浏览器里也有用的原因。

AutoCAD shipped in 1982 with 30 M+ cumulative LOC. Autodesk began compiling to wasm in 2018; AutoCAD Web launched in 2020. The biggest port hurdle wasn't compute speed — it was the filesystem path. AutoCAD assumes a local FS; wasm in the browser has none, so they shim via OPFS (Origin Private File System) and fetch. This is why WASI 0.2's wasi:filesystem matters in the browser too.

Ruffle — Flash 的还魂

Ruffle — Flash, revived

Adobe Flash 2020 年正式 EOL。但无数 90s/00s 的网页游戏 + 互动课件 + 文化档案因此面临"不能再打开"的危机。Ruffle 是一个用 Rust 写的 Flash player,编到 wasm,在浏览器里跑——纯客户端,不需要 Adobe 任何东西。It runs on Internet Archive 上 50 万个 .swf 游戏 / 视频已经"复活"。Ruffle 是 wasm 在文化遗产保存方向最暖的一个故事。

Adobe Flash reached EOL in 2020. But countless 90s/00s web games + interactive coursework + cultural archives faced "cannot be opened again". Ruffle is a Rust-written Flash player, compiled to wasm, running in the browser — pure client-side, Adobe-free. On the Internet Archive, 500 K .swf games and videos have "resurrected" via Ruffle. The warmest wasm story — preservation of cultural heritage.

ffmpeg.wasm — 视频编辑到客户端

ffmpeg.wasm — video editing in the client

把 ffmpeg(2000 万行 C)编到 wasm。生成的 .wasm 大约 25 MB(gzip 后 6 MB)。性能大概是 native ffmpeg 的 40~60%——主要差距在 SIMD 不完全(ffmpeg 用了大量 AVX-512,wasm SIMD 只到 128 bit)。但 client-side 视频转码、抠图、字幕合成全部可以做。1Password、Loom、Riverside、CapCut Web 都集成了 ffmpeg.wasm。

ffmpeg (20 M lines of C) compiled to wasm. Result: ~25 MB .wasm (6 MB gzipped). Perf is 40–60% of native ffmpeg — the gap mostly from SIMD shortfall (ffmpeg uses heavy AVX-512; wasm SIMD caps at 128 bit). Even so, client-side video transcoding, chroma key, subtitle compositing are all on the table. 1Password, Loom, Riverside, CapCut Web all embed ffmpeg.wasm.

服务器端 wasm — 另一半故事

Server-side wasm — the other half of the story

Cloudflare Workers, Fastly Compute@Edge, Shopify Functions, Spin, Fermyon Cloud, NGINX Unit ngx_wasm。这些边缘计算平台不用容器,用 wasm 实例——冷启动 ~ 1 ms(容器 ~ 100 ms),内存隔离更便宜,可以一台机器跑十万个客户。2024 年起服务器端 wasm 实例的总数超过了浏览器。如果你只看浏览器,你只看到了 wasm 故事的一半。

Cloudflare Workers, Fastly Compute@Edge, Shopify Functions, Spin, Fermyon Cloud, NGINX Unit ngx_wasm. These edge platforms don't use containers — they use wasm instances. Cold start ~1 ms (containers ~100 ms), cheaper memory isolation, 100 K tenants per box. From 2024, server-side wasm instances outnumber browser instances. Watching only the browser sees only half the story.

术语表 — 50 个名词,钉死定义

Glossary — 50 terms, pinned definitions

读完这一章你能 hold 住任何 wasm 讨论

after this, you can hold any wasm conversation

读到这里,你已经看完 wasm 从字节到 SIMD 的一生。
下次再有人问 "wasm 是什么"——别用一句话回答。 Field Note · 03 · Final

You have now read the life of wasm, from byte to SIMD.
Next time someone asks "what is wasm" — refuse the one-liner. Field Note · 03 · Final

安全模型 — 三层沙箱与 Spectre 之后

Security model — three sandbox layers, and what came after Spectre

type safety · memory safety · CFI

type safety · memory safety · CFI

三层沙箱

Three sandbox layers

Spectre 时刻 — 2018 年 1 月

The Spectre moment · January 2018

2018 年 1 月 3 日,Spectre / Meltdown 漏洞披露。这两个漏洞利用CPU 推测执行 + cache 时序 旁路通道,可以从一个进程读到另一个进程的内存。wasm threads 当时正好处在 phase 3、即将 ship 阶段——共享内存 + 高精度计时器(performance.now() 当时还是 5 µs 精度)就是 Spectre 的完美材料。

On 3 Jan 2018, Spectre / Meltdown were disclosed. Both exploit CPU speculative execution + cache timing side channels to read another process's memory. Wasm threads were at phase 3, on the verge of shipping — shared memory + high-precision timers (performance.now() at the time was 5 µs precise) were perfect Spectre ingredients.

所有浏览器在 24 小时内做了两件事:① 把 performance.now() 精度降到 ms 级;② 关闭 SharedArrayBuffer。wasm threads 推迟一年半。最终方案是用进程隔离(COOP/COEP 头)让每个站点跑在独立进程里——旁路通道泄漏只能泄漏自己的数据,无意义。这是 web 平台史上第一次因为硬件漏洞推迟了一个软件特性。

All browsers shipped two fixes within 24 hours: ① coarsen performance.now() to ms precision; ② disable SharedArrayBuffer. Wasm threads slid 18 months. The eventual fix used process isolation (COOP/COEP headers) — each site runs in its own process, so side-channel leaks only reveal its own data. The first time the web platform delayed a software feature because of a hardware vulnerability.

真实 CVE 历史(2017-2025)

Real CVE history · 2017–2025

注意一个模式:所有 CVE 都是引擎实现 bug,没有规范级漏洞——这正是 mechanised proof 的胜利。spec 是数学上正确的,但 V8/SM/JSC 必须把它落地到 C++ 代码,这一步会出错。各浏览器现在都跑 fuzzing 工具(wasm-mutate、OSS-Fuzz)持续测试,每个月在主线分支上跑数万 CPU 小时。

A pattern: every CVE is an implementation bug, never a spec-level hole — the win of mechanised proof. The spec is mathematically sound; V8/SM/JSC must land it in C++ and that's where errors creep in. Browsers now run continuous fuzzing (wasm-mutate, OSS-Fuzz) — tens of thousands of CPU-hours per month on the main branches.

服务端 wasm — 另一半故事,1 ms 冷启动的诱惑

Server-side wasm — the other half of the story, the 1 ms cold start

CF Workers · Spin · Fermyon · Wasmtime

CF Workers · Spin · Fermyon · Wasmtime

六大平台对比

Six platforms compared

为什么不是容器

Why not containers

数字差 2 个数量级。这让 wasm 在函数即服务(FaaS)场景里成为唯一可行的隔离方案——AWS Lambda 用容器,冷启动 100 ms~3 s 是真实痛点;Cloudflare Workers 用 V8 isolate(算 wasm 半亲戚),冷启动 5 ms;Fastly 用 Wasmtime,1 ms。同样的代码,延迟差 100 倍。

Two orders of magnitude difference. That makes wasm the only viable isolation model for function-as-a-service — AWS Lambda runs containers, cold-starts of 100 ms–3 s are a real pain point; Cloudflare Workers run V8 isolates (a wasm half-sibling) at ~5 ms; Fastly runs Wasmtime at ~1 ms. Same code, 100× latency gap.

WASI 0.2 — 服务端 wasm 的"统一系统接口"

WASI 0.2 — the "unified system interface" for server wasm

浏览器 wasm 通过 import 拿到 JS 函数;服务端 wasm 通过 import 拿到系统接口——文件读写、网络、时钟、随机数。MVP 时代每家平台都自己定义,Cloudflare 的 API ≠ Fastly 的 API ≠ Wasmtime 的 API。WASI 0.2 (2024 ship) 用 Component Model 把这套接口标准化成一组 .wit 文件:wasi:io / wasi:filesystem / wasi:http / wasi:clocks / wasi:random / wasi:sockets。同一个 wasm 组件可以跑在所有支持 WASI 0.2 的平台——这才是真正的 "compile once, run anywhere"。

Browser wasm gets JS functions via import; server wasm gets system interfaces via import — file I/O, networking, clocks, randomness. In the MVP era every platform defined its own; Cloudflare's API ≠ Fastly's ≠ Wasmtime's. WASI 0.2 (shipped 2024) standardised them as Component Model .wit files: wasi:io / wasi:filesystem / wasi:http / wasi:clocks / wasi:random / wasi:sockets. One wasm component runs on every WASI 0.2-compliant platform — the real "compile once, run anywhere".

服务端 wasm 的真实限制

Real limitations of server-side wasm

wasm 不能做什么 — 反向定义工程边界

What wasm cannot do — defining the boundary in reverse

七个硬限制及它们的绕过办法

seven hard limits and how to route around them

wasm 的"不能",定义了它的"能"。 Field Note · 03 · Appendix

Wasm's "cannot"
defines its "can". Field Note · 03 · Appendix

References & Standards — 文章每个论断的出处

References & Standards — sources for every claim

W3C · IETF · IEEE · 学术 · 源码

W3C · IETF · IEEE · academia · source

A · 核心 W3C 标准

A · Core W3C standards

B · 单独提案(每个有自己的 GitHub spec 仓库)

B · Individual proposals (each with its own GitHub spec repo)

C · 底层标准依赖(IEEE / IETF / DWARF)

C · Underlying standards (IEEE / IETF / DWARF)

D · WASI / Component Model / 非浏览器

D · WASI / Component Model / non-browser

E · 学术论文

E · Academic papers

F · 源码定位

F · Source code anchors

G · 治理 · 历史

G · Governance · history

技术写作的鉴别度
不在花活,在出处。 Field Note · 03 · Appendix

Technical writing is judged not by flourishes,
but by the rigour of its sources. Field Note · 03 · Appendix