Why V8 Copies Built‑in Methods Near JIT Code to Beat Branch‑Prediction Penalties

V8 built‑in methods are essentially code snippets; JIT‑generated code frequently calls these built‑ins, such as standard library functions or code that bridges high‑level JavaScript semantics and the CPU.

On 64‑bit architectures these snippets reside far from the JIT‑generated code in memory, so calls must use registers and memory operands, relying heavily on the CPU’s branch predictor; mispredictions cause significant performance loss.

Branch prediction is a key technique in modern CPUs that guesses which path of a conditional branch will be taken before the branch instruction finishes executing, keeping the instruction pipeline busy. Without prediction, the processor must wait for the branch to resolve before fetching the next instructions, causing pipeline stalls.

The predictor selects the most likely branch, allowing execution to continue speculatively. If the prediction is wrong, the speculative results are discarded and the correct path is fetched, incurring a delay of typically 10–20 clock cycles on CPUs with long pipelines.

Although CPUs support indirect branch prediction for distant calls, performance degrades when the target distance exceeds 4 GB. On Apple M1 chips, large buffer reordering leads to frequent mispredictions and severe performance penalties.

To avoid these costly mispredictions—and because many devices or operating systems disable indirect branch prediction—V8 copies built‑in methods into its pointer‑compression region on machines with sufficient memory. This places the copied code close to dynamically generated code, enabling direct calls and reducing the distance to a few megabytes, increasing each V8 instance’s memory footprint by roughly 1.2–1.4 MiB.