Add a Wasm JIT Using Your Knowledge from Track 2

JIT for Wasm

Once you have an interpreter, compiling hot Wasm functions to native code removes dispatch overhead. Template or trace JITs map Wasm opcodes to machine instructions, reusing techniques from your bytecode VM track.

Compilation Strategy

Approaches:

• Template JIT: one native snippet per Wasm opcode, stitched in order
• Baseline + optimizing: quick code first, recompile with profiling (production engines)
• Bounds check elimination: prove memory safe, elide redundant traps

Executable memory via \`mmap\` + \`mprotect\` matches what you built for the bytecode VM JIT task.

For example, \`i32.add\` becomes x86 \`add\` after two loads from the Wasm stack slots mapped to registers or a native stack frame.

Fallback to the interpreter keeps rare opcodes simple.

Design Notes

Map Wasm locals to native stack slots or registers consistently for the whole function. Changing mapping mid-function makes debugging generated code nearly impossible without a side table.

For This Exercise

This exercise asks you to add a basic JIT to your Wasm runtime using prior JIT knowledge. You will emit native code for a short Wasm function and call it instead of interpreting opcode by opcode.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.