SYSTEM Cited by 2 sources

V8 JavaScript Engine

V8 is Google's open-source JavaScript and WebAssembly engine, written in C++. Originally built for Chrome, V8 is now embedded by many other runtimes — the design was explicitly embedder-oriented from early on. Currently embedded by at least:

• Google Chrome / Chromium
• Node.js
• Deno
• Cloudflare Workers (via V8 isolates; see systems/cloudflare-workers)
• Electron, Cypress, …

Embedder-visible knobs

V8 exposes runtime tuning knobs to the embedder. Relevant to ingested sources:

• Young-generation size (see concepts/v8-young-generation) — the embedder can cap / size the young space manually or let V8 choose heuristically. Cloudflare Workers had historically set this manually based on 2017-era V8 guidance for 512 MB envs — they reverted that tuning in 2025-10 and got ~25 % benchmark wins plus a small memory-usage increase.
• Compile-time flags such as V8_USE_LIBM_TRIG_FUNCTIONS that select between faster and more-portable implementations of math primitives. The flag is on by default in Cloudflare Workers (coincidentally, per the 2025-10 post) and off in Node.js — which explains the 3×-faster trig observed in the original benchmark and is the subject of Cloudflare's nodejs PR #60153.

Cross-ecosystem fix shape

Because so many runtimes embed V8, a V8-level fix compounds across all embedders. Cloudflare's 2025-10 upstream patch to JSON.parse(text, reviver) (Chromium CL 7027411) gives roughly 33 % speedup on that reviver path. It ships in V8 14.3 / Chrome 143 and benefits Node.js, Chrome, Deno, and the rest of the V8 embedder set — not just Workers. This is the load-bearing shape of patterns/upstream-the-fix.

"We've upstreamed a V8 patch that can speed up JSON.parse() with revivers by roughly 33 percent. That should be in V8 starting with version 14.3 (Chrome 143) and can help everyone using V8, not just Cloudflare: Node.js, Chrome, Deno, the entire ecosystem." (Source: sources/2025-10-14-cloudflare-unpacking-cloudflare-workers-cpu-performance-benchmarks)

Cloudflare's seat at V8

Cloudflare's Workers runtime team employs multiple core V8 contributors, which is why the "we fixed this in V8 upstream" pattern is cheap for them in engineering-effort terms.

Seen in

• sources/2025-10-14-cloudflare-unpacking-cloudflare-workers-cpu-performance-benchmarks — canonical wiki instance of V8-embedder tuning affecting user-visible performance (Workers' young-gen manual cap, trig compile flag) and of Cloudflare's V8-patch-level fix mode.
• sources/2026-02-27-cloudflare-a-better-streams-api-is-possible-for-javascript — V8's promise / microtask machinery is the cost substrate behind Web streams' 10-25× performance gap; per-call promise allocation cost lands in V8's young generation as short-lived object churn driving GC to up to 50 %+ of SSR CPU per request. Cross-embedder framing (Chrome + Node + Deno + Workers + Bun all share V8's cost model).

Related

• systems/cloudflare-workers — the primary Cloudflare V8 embedder.
• systems/nodejs — sibling V8 embedder; Vercel's Node.js fast-webstreams work targets V8-level promise elision.
• systems/web-streams-api — the API whose Web-streams performance is dominated by V8 promise/microtask cost.
• systems/new-streams — POC alternative designed to minimize V8 promise allocation via batched chunks + sync fast paths.
• concepts/v8-young-generation — the GC-space knob Cloudflare re-tuned in 2025-10.
• concepts/garbage-collection — storage-GC sibling concept (different substrate; note this wiki's existing garbage- collection page is storage-focused, not V8-focused).
• concepts/promise-allocation-overhead — the V8-substrate cost that dominates Web streams hot paths.
• concepts/hot-path — why tiny V8-level wins compound.
• patterns/upstream-the-fix — the contribution shape V8's embedder structure invites.