\n\nWritten against V8 v11.x. This goes past the usual “what is a garbage collector” tour and into how V8 handles millions of function calls per second and gigabytes of heap without the user noticing.
\n
JavaScript went from a scripting language to a platform for real applications largely because V8 got good at managing memory. Early V8 stopped the world for tens of milliseconds at a time; today the same work finishes in single-digit milliseconds. The story of how that happened starts one level below the collector, with the way objects are laid out in the first place.
\nInternally every JavaScript object is a HeapObject, and it looks roughly like this:
// V8's internal object layout (simplified)\nclass HeapObject {\n Map* map_; // Hidden Class pointer (4/8 bytes)\n Properties* props_; // dynamic property backing store\n Elements* elements_; // array element backing store\n // ... inline properties\n};Hidden Classes (Maps, in V8’s own vocabulary) are the trick that lets a dynamically typed language reach statically typed performance. Every time an object’s shape changes, V8 transitions it to a new Hidden Class, and those transitions feed the Inline Cache (IC) that makes property access fast.
\nThat’s the payoff. The cost is that this is a lot of structure to keep alive, and keeping it alive cheaply is what the rest of this post is about.
\nA modern web app holds a large heap, animates at 60FPS and expects to stay responsive while doing it. The collector has to solve four problems at once:
\nChrome’s Site Isolation raises the stakes further: every iframe gets its own V8 isolate, so per-isolate memory efficiency multiplies. V8’s first answer to all of this is the shape of the heap itself.
\nV8’s heap is more than a Young/Old split. The real structure is layered:
\nV8 Heap (tens of MB to a few GB)\n├── Young Generation (1-32MB)\n│ ├── Nursery (Semi-space 1)\n│ ├── Intermediate (Semi-space 2)\n│ └── Survivor Space\n├── Old Generation\n│ ├── Old Object Space\n│ ├── Code Space (executable code)\n│ ├── Map Space (Hidden Classes)\n│ └── Large Object Space (objects >256KB)\n└── Non-movable Spaces\n ├── Read-only Space\n └── Shared Space (cross-isolate)Splitting the heap by object lifetime lets each region be collected the way that suits it. Allocation itself is nearly free: each thread gets its own TLAB (Thread-Local Allocation Buffer) so threads don’t contend, and inside a TLAB allocation is a bump pointer, which is O(1).
\nAll of which rests on one assumption. We’ll get to whether it holds.
\nPromotion from Young to Old isn’t a simple age counter. V8 uses a mix of heuristics:
\n// Pretenuring: V8 learns the pattern\nfunction createLargeObject() {\n return new Array(1000000); // after enough calls, allocated directly in Old Space\n}The write barrier is what makes generational collection possible at all. When an old object starts pointing at a young one, that slot goes into a remembered set and is treated as a root during Minor GC:
\n// Write barrier (simplified)\nif (is_old_object(obj) && is_young_object(value)) {\n remembered_set.insert(obj_address);\n}V8’s own measurements say yes, emphatically:
\nWhich explains why generational collection works so well, right up until you put React on top of it, where the assumption comes apart.
\nThe Fiber architecture that landed in React 16 runs almost exactly counter to the generational hypothesis.
\n// React Fiber node (simplified)\nclass FiberNode {\n constructor(element) {\n this.type = element.type;\n this.key = element.key;\n this.props = element.props;\n\n // these references are the whole problem\n this.child = null; // child fiber\n this.sibling = null; // sibling fiber\n this.return = null; // parent fiber\n this.alternate = null; // previous render's fiber (double buffering)\n\n // and these survive a long time\n this.memoizedState = null; // hook state\n this.memoizedProps = null; // previous props\n this.updateQueue = null; // update queue\n }\n}\n\n// the fiber tree in a real app\nconst fiberRoot = {\n current: rootFiber, // current tree (promoted to Old Generation)\n workInProgress: null, // in-progress tree (Young Generation)\n pendingTime: 0,\n finishedWork: null\n};Three consequences. Fiber nodes live as long as the component is mounted. Every render keeps an alternate fiber around for double buffering. And the whole tree ends up in the Old Generation, which is the expensive one to collect.
\n// the classic leak\nfunction ExpensiveComponent() {\n const [data, setData] = useState([]);\n\n useEffect(() => {\n // this closure captures the entire component scope\n const timer = setInterval(() => {\n setData(prev => [...prev, generateLargeObject()]);\n }, 1000);\n\n // forget this return and you've leaked\n return () => clearInterval(timer);\n }, []); // empty deps still allocates the closure\n\n // a fresh function every render, so more pressure on the Young Generation\n const handleClick = useCallback(() => {\n // captures all of data\n console.log(data.length);\n }, [data]);\n}\n\n// a hook pattern V8 has trouble with\nfunction useComplexState() {\n const [state, setState] = useState(() => {\n // runs exactly once, but V8 can't easily know that\n return createExpensiveInitialState();\n });\n\n // the hook linked list is more work for the collector\n const hook = {\n memoizedState: state,\n queue: updateQueue,\n next: nextHook\n };\n}// how virtual DOM objects get made\nfunction createElement(type, props, ...children) {\n return {\n $$typeof: REACT_ELEMENT_TYPE,\n type,\n key: props?.key || null,\n ref: props?.ref || null,\n props: { ...props, children },\n _owner: currentOwner // fiber reference\n };\n}\n\n// temporaries, one full set per render\nfunction render() {\n // every one of these lands in the Young Generation\n return (\n <div className=\"container\">\n {items.map(item => (\n <Item\n key={item.id}\n data={item}\n onClick={() => handleClick(item.id)}\n />\n ))}\n </div>\n );\n // and most of it is garbage the moment reconciliation ends\n}\n\n// plus the work objects reconciliation itself allocates\nconst updatePayload = {\n type: 'UPDATE',\n fiber: currentFiber,\n partialState: newState,\n callback: commitCallback,\n next: null // update queue linked list\n};To be fair to React, this is the shape of the problem, not a mistake. The garbage is short-lived, which is exactly what scavenging is good at. The trouble is the part that isn’t garbage.
\n// memory React DevTools costs you in development\nif (__DEV__) {\n // debug info hung off every fiber\n fiber._debugSource = element._source;\n fiber._debugOwner = element._owner;\n fiber._debugHookTypes = hookTypes;\n\n // and profiling timings\n fiber.actualDuration = 0;\n fiber.actualStartTime = 0;\n fiber.selfBaseDuration = 0;\n fiber.treeBaseDuration = 0;\n}\n\n// GC-conscious component\nclass MemoryOptimizedComponent extends React.Component {\n shouldComponentUpdate(nextProps) {\n // fewer renders, fewer virtual DOM objects\n return !shallowEqual(this.props, nextProps);\n }\n\n componentDidMount() {\n // WeakMap so the cache doesn't pin anything\n this.cache = new WeakMap();\n }\n\n componentWillUnmount() {\n // explicit cleanup\n this.cache = null;\n this.subscription?.unsubscribe();\n }\n}// automatic batching\nfunction handleMultipleUpdates() {\n // before: each setState triggered its own render\n // now: batched, which means less garbage\n setCount(c => c + 1);\n setFlag(f => !f);\n setItems(i => [...i, newItem]);\n}\n\n// Suspense keeps the initial heap smaller\nconst LazyComponent = React.lazy(() => {\n return import('./HeavyComponent');\n});\n\n// useDeferredValue spreads allocation over time\nfunction SearchResults({ query }) {\n const deferredQuery = useDeferredValue(query);\n\n // non-urgent updates get deferred,\n // which flattens the Young Generation spike\n return <ExpensiveList query={deferredQuery} />;\n}// object pooling, as used in Facebook's list virtualization\nconst RecyclerListView = {\n viewPool: [],\n\n getView() {\n return this.viewPool.pop() || this.createView();\n },\n\n releaseView(view) {\n view.reset();\n this.viewPool.push(view);\n }\n};\n\n// Relay's cache, built to stay collectable\nclass RelayCache {\n constructor() {\n // weak keys, automatic cleanup\n this.records = new WeakMap();\n\n // TTL so the Old Generation doesn't just grow\n this.ttl = 5 * 60 * 1000; // 5 minutes\n }\n\n gc() {\n const now = Date.now();\n for (const [key, record] of this.records) {\n if (now - record.fetchTime > this.ttl) {\n this.records.delete(key);\n }\n }\n }\n}None of this is a standoff. The V8 and React teams have been working on it from both ends for years, and React 18’s concurrent features were designed with V8’s incremental GC in mind. If you want the definitive account of one of these collisions, V8’s own post on the React performance cliff is worth your time.
\nA generational heap alone doesn’t get you there. The real question is how to collect garbage without stopping the application, and V8’s history is basically a long series of answers to it.
\nIn 2008, V8 shipped a semi-space collector built on Cheney’s algorithm, the textbook copying collector.
\n// Cheney's algorithm, in pseudocode\nvoid scavenge() {\n scan = next = to_space.bottom;\n // 1. scan the roots\n for (root in roots) {\n *root = copy(*root);\n }\n // 2. breadth-first from there\n while (scan < next) {\n for (slot in slots_in(scan)) {\n *slot = copy(*slot);\n }\n scan += object_size(scan);\n }\n}Simple and fast, with three problems that turn fatal at web-app scale. It wastes 50% of the space by design, since half the semi-space is always empty. Its breadth-first traversal is hostile to cache locality: objects that are used together end up far apart, and you pay for it in L1/L2 misses. And all of it happens on the main thread.
\nV8 moved to tri-color marking, which is what makes incremental marking possible.
\n// tri-color invariant\nenum MarkColor {\n WHITE = 0, // unvisited, collectable\n GREY = 1, // visited, children not yet processed\n BLACK = 2 // fully visited, live\n};\n\n// the barrier that keeps incremental marking honest\nvoid WriteBarrier(HeapObject* obj, Object** slot, Object* value) {\n if (marking_state == INCREMENTAL &&\n IsBlack(obj) && IsWhite(value)) {\n // a black object must never point at a white one\n MarkGrey(value);\n marking_worklist.Push(value);\n }\n}Now marking can proceed a slice at a time while JavaScript runs in between. Progress, but the marking still happens on the main thread, and that’s the part worth attacking.
\nIncremental wasn’t enough. Orinoco, started in 2015, was V8’s ground-up rework of the collector under a deliberately aggressive banner: free the main thread. Three techniques came out of it.
\nMultiple threads doing GC work at the same time, balanced with work stealing:
\nclass ParallelMarker {\n std::atomic<Object*> marking_worklist;\n std::atomic<size_t> bytes_marked;\n\n void MarkInParallel() {\n while (Object* obj = marking_worklist.pop()) {\n MarkObject(obj);\n // when the local queue runs dry, take work from a neighbour\n if (local_worklist.empty()) {\n StealFromOtherThread();\n }\n }\n }\n};On an 8-core machine, parallel marking measured 7.2x faster than single-threaded. Fast, but the application is still stopped while it happens.
\nIncremental marking chops the work into slices of 5-10ms:
\n// deciding when to run a step\nfunction shouldTriggerIncrementalStep() {\n const allocated = bytesAllocatedSinceLastStep();\n const threshold = heap.size() * 0.01; // 1% of heap\n return allocated > threshold;\n}\n\n// roughly 1MB of marking per step\nfunction incrementalMarkingStep() {\n const deadline = performance.now() + 5; // 5ms budget\n while (performance.now() < deadline && !marking_worklist.empty()) {\n markNextObject();\n }\n}Internally V8 tracks a marking progress bar so that marking speed keeps pace with allocation speed. Important, but still main-thread work. The real answer was to get off it entirely.
\nConcurrent marking is the hardest of the three and by far the most effective. V8 uses snapshot-at-the-beginning (SATB):
\nclass ConcurrentMarker {\n void WriteBarrierSATB(HeapObject* obj, Object** slot, Object* new_value) {\n Object* old_value = *slot;\n if (concurrent_marking_active &&\n IsWhite(old_value) && !IsWhite(new_value)) {\n // preserve the old reference for the snapshot\n satb_buffer.push(old_value);\n }\n *slot = new_value;\n }\n\n void ConcurrentMarkingTask() {\n // running on a helper thread\n while (!marking_worklist.empty()) {\n Object* obj = marking_worklist.pop();\n // lock-free marking via CAS\n if (TryMarkBlack(obj)) {\n VisitPointers(obj);\n }\n }\n }\n};Concurrent marking cut Major GC pause times by 60-70%.
\nThose three ideas are now the core of the collector. Here’s how each phase uses them.
\nYoung GC is fully parallel. The main thread does stop, but only briefly, while several helper threads work at once.
\nclass ParallelScavenger {\n void Scavenge() {\n // 1. scan roots in parallel\n parallel_for(roots, [](Root* root) {\n EvacuateObject(root->object);\n });\n\n // 2. work stealing keeps threads busy\n while (has_work() || can_steal_work()) {\n Object* obj = get_next_object();\n CopyToSurvivor(obj);\n }\n\n // 3. pointer updates go parallel too\n parallel_update_pointers();\n }\n};On an 8-core machine that took Young GC from 50ms down to 7ms.
\nOld GC leans on concurrency wherever it can:
\n// what the timeline looks like\n[JS running]-->[concurrent marking starts]-->[JS]-->[5ms step]-->[JS]-->[2ms finalize]-->[JS]\n ↑ ↑ ↑ ↑\nallocation limit background work cooperative minimal pauseChrome’s idle periods are a resource, and V8 spends them:
\n// hooked into requestIdleCallback\nrequestIdleCallback((deadline) => {\n const timeRemaining = deadline.timeRemaining();\n\n if (timeRemaining > 10) {\n // enough room for a major collection\n triggerMajorGC();\n } else if (timeRemaining > 2) {\n // just enough for a minor one\n triggerMinorGC();\n }\n});The combination is why you can hold 60FPS and still have the heap under control. The collector does most of its work in the gaps.
\nEverything in concurrent marking exists to preserve the tri-color invariant while the mutator keeps changing the graph underneath it.
\nclass ConcurrentMarkingVisitor {\n void VisitPointers(HeapObject* host, ObjectSlot start, ObjectSlot end) {\n for (ObjectSlot slot = start; slot < end; ++slot) {\n Object* target = *slot;\n\n // 1. already handled\n if (IsBlackOrGrey(target)) continue;\n\n // 2. CAS, because other threads are doing the same thing\n if (CompareAndSwapColor(target, WHITE, GREY)) {\n // 3. push onto a lock-free worklist\n marking_worklist_.Push(target);\n\n // 4. and record the cross-generation reference\n if (host->IsInOldSpace()) {\n remembered_set_.Insert(slot);\n }\n }\n }\n }\n};class WorkStealingQueue {\n bool TrySteal(Object** obj) {\n // 1. local queue first\n if (local_queue_.Pop(obj)) return true;\n\n // 2. empty? steal from someone else\n for (int i = 0; i < num_threads; i++) {\n if (global_queues_[i].TryStealHalf(&local_queue_)) {\n return local_queue_.Pop(obj);\n }\n }\n\n // 3. everyone's empty, so we're done\n return false;\n }\n};The object graph is wildly uneven. One thread can draw a subtree with a hundred thousand nodes while another gets three, so static partitioning would leave most cores idle. Stealing is what turns extra cores into actual speed.
\nMemory is half the story. The other half is how JavaScript gets turned into machine code, and V8’s compiler pipeline has been rebuilt just as thoroughly as its collector.
\nTwo compilers, one fast and one good.
\n// the kind of function that gets optimized\nfunction calculateSum(arr) {\n let sum = 0;\n for (let i = 0; i < arr.length; i++) {\n sum += arr[i]; // hot loop, Crankshaft's territory\n }\n return sum;\n}\n\n// Full-codegen: compiles fast, runs slow\n// -> every function goes straight to native code\n\n// Crankshaft: compiles slow, runs fast\n// -> only hot functions get this treatmentIt worked, and then it stopped scaling. Compiling everything to native code costs a lot of memory. Deoptimization happened constantly. And Crankshaft simply couldn’t handle a lot of the JavaScript people were actually writing: try/catch, generators, let/const in some positions.
In 2016 the team replaced the whole pipeline. Ignition is an interpreter that compiles JavaScript to compact bytecode, cutting memory use by 50-75% versus Full-codegen. TurboFan replaced Crankshaft as the optimizing compiler and does considerably more sophisticated work.
\n// the path a function takes\nfunction Component({ data }) {\n // 1. parse -> AST\n // 2. Ignition lowers it to bytecode\n const result = data.map(item => item * 2);\n\n // 3. execution counts and type info accumulate (feedback vector)\n // 4. hot enough, and TurboFan takes over\n return result;\n}\n\n// roughly what the bytecode looks like\n/*\n LdaNamedProperty a0, [0] // load data\n CallProperty1 [1], a0, a1 // call map\n Return\n*/The wins compound. Bytecode is much smaller than native code, which matters enormously on mobile. It’s generated fast, so startup improves. And optimization becomes something you spend only where it pays.
\nInline caching attacks the single biggest tax on a dynamic language: property access. Every obj.property in principle requires checking the object’s shape and then finding the property. An IC remembers what it saw last time at that call site and skips the lookup when the shape matches.
Hidden Classes are what it matches against, the internal metadata describing an object’s shape. Objects with the same properties added in the same order share one, and that sharing is what gets property access down to something close to a C++ struct field load.
\n// how transitions happen\nclass Point {\n constructor(x, y) {\n this.x = x; // Hidden Class C0 -> C1\n this.y = y; // Hidden Class C1 -> C2\n }\n}\n\n// monomorphic: one shape, fully optimizable\nfunction getX(point) {\n return point.x;\n}\n\n// polymorphic: many shapes, much harder\nfunction getValue(obj) {\n return obj.value;\n}\n\n// in a component\nfunction UserProfile({ user }) {\n // consistent props shape means the IC stays hot\n return <div>{user.name}</div>;\n}\n\n// and the anti-pattern\nfunction BadComponent({ data }) {\n if (someCondition) {\n data.extraField = 'value'; // shape change, cache blown\n }\n return <div>{data.value}</div>;\n}V8’s adaptive optimization decides what to compile based on what actually runs, in three stages:
\nThe point of the loop is that optimization follows real usage instead of a guess, so you don’t spend compile time on code nobody calls twice.
\n// the three tiers, side by side\nclass OptimizationExample {\n // cold: interpreted, and that's fine\n rarely_called() {\n return Math.random();\n }\n\n // warm: type feedback accumulating\n sometimes_called(x, y) {\n return x + y;\n }\n\n // hot: TurboFan compiles this\n frequently_called(arr) {\n let sum = 0;\n for (let i = 0; i < arr.length; i++) {\n sum += arr[i];\n }\n return sum;\n }\n}\n\n// what gets recorded per call site\nlet feedback = {\n callCount: 0,\n parameterTypes: [],\n returnTypes: []\n};\n\n// render functions are called constantly, so they optimize well\nfunction FrequentlyRendered({ items }) {\n return items.map((item, i) => (\n <Item key={i} data={item} />\n ));\n}TurboFan isn’t a simple JIT. It builds a Sea of Nodes intermediate representation and runs real optimization passes over it.
\n// 1. inlining\n// removes call overhead, typically 10-30%\nfunction add(a, b) { return a + b; }\nfunction calculate(x, y) {\n return add(x, y) * 2;\n // after inlining: return (x + y) * 2;\n // and now further optimizations become visible\n}\n\n// 2. escape analysis\n// an object that never leaves the function never needs the heap\nfunction createPoint() {\n const point = { x: 10, y: 20 }; // would normally be heap-allocated\n return point.x + point.y; // but it never escapes\n // after optimization: return 30;\n // no allocation, nothing for the collector to do\n}\n\n// 3. loop optimizations\nfunction processArray(arr) {\n // unrolling: fewer iterations, fewer branch mispredictions\n for (let i = 0; i < arr.length; i += 4) {\n arr[i] = arr[i] * 2;\n arr[i+1] = arr[i+1] * 2;\n arr[i+2] = arr[i+2] * 2;\n arr[i+3] = arr[i+3] * 2;\n }\n // up to 4x on the right workload, thanks to pipeline utilization\n}\n\n// 4. and how React benefits\nconst MemoizedComponent = React.memo(({ data }) => {\n // the props comparison itself gets optimized\n return <ExpensiveRender data={data} />;\n});You don’t have to take any of this on faith. Chrome DevTools’ Performance panel shows it, and Node’s --trace-opt flag shows it in more detail.
// crude but effective\nfunction profileFunction() {\n // 1. first run: interpreted\n console.time('cold');\n calculateSum([1,2,3,4,5]);\n console.timeEnd('cold');\n\n // 2. warm it up\n for (let i = 0; i < 1000; i++) {\n calculateSum([1,2,3,4,5]);\n }\n\n // 3. now it's compiled\n console.time('hot');\n calculateSum([1,2,3,4,5]);\n console.timeEnd('hot'); // noticeably faster\n}\n\n// or watch the decisions directly\n// node --trace-opt --trace-deopt script.jsReact was written by people who knew what V8 rewards, and React 18’s concurrent features fit the engine’s optimization model closely.
\n// compiler-friendly by construction\nfunction OptimizedComponent() {\n // 1. stable types\n const [count, setCount] = useState(0); // always a number\n\n // 2. predictable structure\n const content = useMemo(() => {\n return count > 10 ? <Heavy /> : <Light />;\n }, [count]);\n\n // 3. stable function identity\n const handleClick = useCallback((e) => {\n // same reference every render, so the IC stays monomorphic\n setCount(c => c + 1);\n }, []);\n\n return <div onClick={handleClick}>{content}</div>;\n}\n\n// React Compiler (experimental) pushes this further,\n// doing at build time what would otherwise be runtime workA handful of common patterns actively fight the optimizer. Fixing them is often worth 2-10x.
\n// anti-pattern 1: churning the Hidden Class\nfunction bad() {\n const obj = {};\n obj.a = 1; // HC1\n obj.b = 2; // HC2\n delete obj.a; // HC3, and now you're deoptimized\n}\n\n// fix: declare the shape up front\nfunction good() {\n const obj = { a: 1, b: 2 };\n if (needToRemove) {\n obj.a = undefined; // undefined instead of delete\n }\n}\n\n// anti-pattern 2: too many shapes at one call site\nfunction processItems(items) {\n items.forEach(item => {\n // item is a different shape every time, so nothing to cache\n console.log(item.value);\n });\n}\n\n// fix: one shape\ninterface Item {\n value: number;\n type: string;\n}\nfunction processTypedItems(items: Item[]) {\n items.forEach(item => console.log(item.value));\n}Compilers made JavaScript fast, and frameworks like React quietly do the work of staying on the fast path so you mostly don’t have to think about it. But none of it survives careless memory use, which brings us back to the heap.
\nAround the core collector sits a set of smaller optimizations. Each one only matters in particular situations, but where they apply they matter a lot.
\nPooling means creating objects once and reusing them instead of allocating and discarding. It pays off in exactly the places you’d expect: games, animation, anything that produces hundreds of objects per frame.
\nInstead of letting an object die, you hand it back to a pool and take it out again when you need one. Young Generation pressure drops, and so does collection frequency.
\n// a pool, minus the details\nclass ObjectPool {\n constructor(createFn, maxSize = 100) {\n this.createFn = createFn;\n this.pool = Array(maxSize).fill(null).map(createFn);\n }\n\n acquire() {\n return this.pool.pop() || this.createFn();\n }\n\n release(obj) {\n this.pool.push(obj);\n }\n}\n\n// bullets in a game, for instance\nconst bulletPool = new ObjectPool(\n () => ({ x: 0, y: 0, active: false }),\n 1000\n);Measured on a particle system, pooling cut GC pauses by 70% and effectively eliminated dropped frames. The gap was widest on mobile, where there’s less headroom to hide a pause in.
\n// the difference, concretely\nconst particles = [];\nfor (let i = 0; i < 10000; i++) {\n // without pooling: a new object every iteration\n particles.push({ x: Math.random() * 800, y: 600 });\n\n // with pooling: reuse\n // const p = pool.acquire();\n // p.x = Math.random() * 800;\n}Worth saying: pooling is not free. You’re taking manual responsibility for object lifetimes in a language that was designed to take that away from you, and a pooled object that keeps a stale reference is a leak the collector can’t help you with. Reach for it when you’ve measured a problem, not by default.
\nFragmentation is the chronic disease of long-running applications. Allocate and free objects of varying sizes for long enough and the heap fills with holes too small to use. You have plenty of free memory and still can’t satisfy a large allocation.
\nV8’s answer is to move live objects together during Major GC, consolidating the free space behind them. It’s expensive, which is why V8 prefers to do it during idle time.
\n// how fragmentation gets made\nclass FragmentationExample {\n constructor() {\n this.data = [];\n\n // mix large and small objects, free some of each,\n // and the free space ends up scattered\n }\n}\n\n// what you can do about it from the outside\nconst optimized = {\n smallObjects: [], // group by size\n largeObjects: [],\n buffer: new ArrayBuffer(1024 * 1024), // or take contiguous memory yourself\n};Shipped in Chrome 80, and one of the largest single memory wins V8 has had. On a 64-bit machine every pointer costs 8 bytes, which for a language that allocates as many small objects as JavaScript is a lot of overhead for very little addressing range that anyone uses.
\nThe trick: confine JavaScript objects to a 4GB “cage” and store addresses within it as 32-bit offsets. Real addresses are reconstructed as base + offset.
\nChrome measured an average 43% reduction in V8 heap usage on typical pages. React apps benefit disproportionately, because a component tree is mostly pointers.
\n// pointer compression (Chrome 80+)\n// before: 8 bytes per reference (64-bit)\n// after: 4 bytes per reference (32-bit offset)\n\nconst obj = {\n ref1: {}, // 8 bytes -> 4 bytes\n ref2: {},\n ref3: {}\n};Interning stores one copy of a given string instead of many, the same idea as Java’s string pool, except V8 does it for you.
\nShort strings and frequently used ones get interned automatically. Event type strings like \"click\" and \"hover\" exist once in memory no matter how many thousands of times they appear.
You can help by reusing string constants rather than constructing equivalent strings at runtime. Redux action types and event names are the usual candidates.
\nconst EVENT_TYPES = {\n CLICK: 'click',\n HOVER: 'hover'\n};\n\n// used 10,000 times, stored once\nevents.push({ type: EVENT_TYPES.CLICK });The weak collections from ES6 are the most direct tool JavaScript gives you for preventing leaks.
\nA regular Map holds its keys strongly. Put a DOM node in one and that node cannot be collected until you remove the entry by hand, and that “by hand” is where leaks come from, because the removal is easy to forget and impossible to notice.
A WeakMap holds its keys weakly. When nothing else references the key, the entry disappears on its own. That makes it the right structure for caches, metadata attached to DOM nodes, and private per-instance data.
// WeakMap: cleans itself up\nconst cache = new WeakMap();\n\nelements.forEach(el => {\n cache.set(el, { data: 'metadata' });\n // remove el from the document and the cache entry goes with it\n});\n\n// Map: your responsibility, and a leak if you forget\nconst map = new Map();These techniques aren’t a checklist to apply all at once. You pick the one that fits the problem. Games and real-time apps get the most out of them.
\nNumbers, before and after:
\nIn SPA workloads, average interaction latency improved roughly 18% after Orinoco landed.
\nImpressive, and then a different kind of workload showed up.
\nWebAssembly is a low-level binary format built to run at near-native speed in a browser. It’s how C++, Rust and Go code ends up on a web page, and V8 has an entire optimization strategy dedicated to executing it well.
\nWASM modules can be several megabytes. Compile them thoroughly and startup is terrible; compile them carelessly and you’ve given up the performance you came for.
\nV8 does what it does for JavaScript: two tiers. Liftoff, a baseline compiler, gets you executing quickly, while TurboFan produces optimized code in the background.
\n// tiered compilation, from the outside\nasync function loadWasm() {\n const response = await fetch('module.wasm');\n // streaming: compile while it downloads\n const module = await WebAssembly.compileStreaming(response);\n\n // Liftoff: ~10ms/MB (baseline, fast)\n // TurboFan: ~100ms/function (optimized, background)\n\n return WebAssembly.instantiate(module, imports);\n}Chrome 96 added dynamic tiering, which decides what to re-compile based on how often each function actually runs. On mobile this matters for battery as much as for speed, since optimizing code nobody calls is pure waste.
\nThe mechanism is straightforward: everything starts on Liftoff, execution counters identify the hot functions, anything past the threshold (roughly 1,000 calls) gets recompiled by TurboFan, and the threshold itself adapts to the workload.
\n// conceptually\nconst funcStats = {\n add: { calls: 0, optimized: false },\n matrixMultiply: { calls: 0, optimized: false }\n};\n\n// past the threshold, recompile\nif (funcStats.matrixMultiply.calls++ > 1000) {\n // Liftoff -> TurboFan\n}\n\n// and from React's side, it's just a module\nconst wasm = await WebAssembly.instantiateStreaming(\n fetch('module.wasm')\n);\nwasm.instance.exports.processImage(data);WebAssembly traditionally used linear memory, one flat byte array. Perfect for C and C++, awkward the moment you want to hand a structured object back and forth with JavaScript.
\nThe WasmGC proposal (Chrome 119+) gives WebAssembly access to the same garbage collector JavaScript uses. That buys you references between JS objects and WASM structs, no manual malloc/free, cycles collected automatically, and a single predictable pause instead of two memory systems with separate behaviors.
// linear memory: still how most WASM works today\nconst memory = new WebAssembly.Memory({\n initial: 256, // 16MB\n maximum: 32768 // 2GB\n});\n\n// moving data across the boundary\nconst view = new Uint8Array(memory.buffer, ptr, size);\nview.set(data); // JS -> WASM\n\n// WasmGC (Chrome 119+): managed objects instead\n// (type $point (struct (field $x f64) (field $y f64)))\n// same collector as JavaScriptSIMD, or single instruction multiple data, processes several values with one instruction. V8 supports WebAssembly SIMD, which means access to the CPU’s vector units from the browser.
\nWhat that’s worth in practice: four floats added at once for a 4x speedup on vector math, roughly 30x on a 512x512 matrix multiply, real-time blur and sharpen filters on images, and fluid simulations that hold 60fps.
\n// scalar JavaScript: one at a time\nfor (let i = 0; i < arr.length; i++) {\n result[i] = a[i] + b[i];\n}\n\n// WASM SIMD: four at a time\n// (f32x4.add (v128.load a) (v128.load b))\n\n// measured: JS ~450ms -> WASM ~50ms -> SIMD ~15msLarge modules (10MB and up) can take seconds to compile. Doing that on every page load is not acceptable, so V8 caches the result: optimized machine code goes into IndexedDB, WebAssembly.Module.serialize() gives you the compiled artifact, a cache hit skips compilation entirely, and timestamps handle invalidation.
// caching compiled modules\nasync function loadWithCache(url) {\n // 1. check the cache\n let module = await cache.get(url);\n\n if (!module) {\n // 2. compile and store\n module = await WebAssembly.compileStreaming(\n fetch(url)\n );\n await cache.store(url, module);\n }\n\n return module; // no recompilation\n}On compute-heavy work like matrix multiplication, WebAssembly runs 9-30x faster than JavaScript. The applications that exist because of that are the real argument: AutoCAD Web renders 3D CAD in a browser, Google Earth streams large 3D map data in real time, Figma runs its vector engine in WASM, and Photoshop Web applies filters at close to native speed.
\n// matrix multiply, 512x512\n// JavaScript: ~450ms\n// WebAssembly: ~50ms (9x)\n// WASM + SIMD: ~15ms (30x)\n\n// image filtering from React\nconst applyFilter = async (imageData) => {\n // JS filter: ~50ms\n // WASM filter: ~5ms\n return wasmFilters[filterType](imageData);\n};The pattern that’s emerging is a split one: JavaScript for business logic and UI, WebAssembly for the parts where the numbers hurt.
\nclass IncrementalRenderer {\n constructor() {\n this.pendingUpdates = new WeakMap();\n this.updateQueue = [];\n }\n\n scheduleUpdate(element, patch) {\n // WeakMap so a detached element doesn't stay pinned\n this.pendingUpdates.set(element, patch);\n\n // spend idle time, not frame time\n requestIdleCallback(() => {\n this.processBatch();\n }, { timeout: 16 }); // one frame\n }\n\n processBatch() {\n const batchSize = 100;\n for (let i = 0; i < batchSize && this.updateQueue.length; i++) {\n const update = this.updateQueue.shift();\n update.apply();\n }\n }\n}Result: 70% fewer major collections, and frames held 95% of the time.
\nclass MessagePool {\n constructor(size = 1000) {\n this.pool = [];\n this.activeMessages = new Set();\n\n // preallocate\n for (let i = 0; i < size; i++) {\n this.pool.push(new Message());\n }\n }\n\n acquire() {\n let msg = this.pool.pop();\n if (!msg) {\n // ran dry, so grow, but say so\n console.warn('Pool expansion triggered');\n msg = new Message();\n }\n this.activeMessages.add(msg);\n return msg.reset();\n }\n\n release(msg) {\n if (this.activeMessages.delete(msg)) {\n this.pool.push(msg);\n }\n }\n}Result: 85% fewer Young Generation collections and 30% less memory used.
\n// GC events via the Performance API\nclass V8Profiler {\n static measureGC() {\n const obs = new PerformanceObserver((list) => {\n for (const entry of list.getEntries()) {\n if (entry.entryType === 'measure' &&\n entry.detail?.kind === 'gc') {\n console.log(`GC Type: ${entry.detail.type}`);\n console.log(`Duration: ${entry.duration}ms`);\n console.log(`Heap Before: ${entry.detail.usedHeapSizeBefore}`);\n console.log(`Heap After: ${entry.detail.usedHeapSizeAfter}`);\n }\n }\n });\n\n obs.observe({ entryTypes: ['measure'] });\n }\n\n static getHeapSnapshot() {\n if (typeof gc !== 'undefined') {\n gc(); // requires --expose-gc\n }\n\n return performance.measureUserAgentSpecificMemory();\n }\n}Pointer compression (Chrome 89)
\nEnvironment: 8GB RAM, 4-core CPU\nApps: Gmail, Google Docs, YouTube\n\nResults:\n- V8 Heap: 1.2GB -> 684MB (43% less)\n- Renderer Memory: 2.1GB -> 1.68GB (20% less)\n- Major GC Time: 45ms -> 38.7ms (14% less)\n- FID p95: 24ms -> 19msOrinoco vs the old collector
\nBenchmark: Speedometer 2.0\n\nLegacy (2015):\n- Score: 45 ± 3\n- GC Pause p50: 23ms\n- GC Pause p99: 112ms\n- Total GC Time: 3.2s\n\nOrinoco (2019):\n- Score: 78 ± 2 (73% better)\n- GC Pause p50: 2.1ms (91% lower)\n- GC Pause p99: 14ms (87% lower)\n- Total GC Time: 0.9s (72% lower)The p99 line is the one to read twice. A p50 of 2ms is nice; a p99 of 112ms dropping to 14ms is the difference between an app that occasionally stutters for no visible reason and one that doesn’t.
\nconst optimizationChecklist = {\n // 1. Hidden Classes\n avoidDynamicProperties: true,\n useConstructorsConsistently: true,\n\n // 2. inline caches\n avoidPolymorphicCalls: true,\n limitFunctionTypes: 4,\n\n // 3. memory\n useObjectPools: true,\n limitClosureScopes: true,\n preferTypedArrays: true,\n\n // 4. fewer collections\n batchDOMUpdates: true,\n useWeakReferences: true,\n clearLargeObjects: true\n};V8 stopped being a JavaScript engine some time ago; it’s a system. It’s not an accident that its components are named after engine parts and car technology: Ignition, TurboFan, Orinoco. That’s the shape of the thing: separate pieces, machined to fit, and the whole point is that they mesh. It’s the reason a browser tab can now do work that used to require a native application.
\nI won’t pretend this was an easy post to write. Most of it came out of V8 team papers, their blog, and reading the source, and some of it I only understood on the third pass. What I keep coming back to is a smaller question than any of the machinery above: given all this engineering, what is it actually asking of us? Mostly, I think, that we stop making the engine guess: keep object shapes stable, keep types consistent, and don’t hold references longer than we need to. None of that is exotic. It’s just the part we’re responsible for.
\nLast thing: thanks to everyone who’s contributed to V8. It’s an extraordinary piece of open source.
\n