V8 Engine Garbage Collection and Memory Allocation

Before diving into V8, the article briefly introduces browser engines, listing the rendering engines (Blink, WebKit, Gecko, Trident) and their associated JavaScript engines (V8, JavaScriptCore, SpiderMonkey, Chakra) in a table.

It then explains that JavaScript itself cannot manage memory; the underlying engine handles garbage collection, and the discussion focuses on V8.

Memory allocation is described by distinguishing stack memory (small, contiguous, automatically managed) from heap memory (larger, non‑contiguous). The article introduces V8's memory classification based on the weak generational hypothesis, which separates objects into a short‑lived "new space" and a long‑lived "old space".

The young generation uses the Scavenge algorithm, which divides the space into two equal semispaces (from‑space and to‑space). When from‑space fills up, V8 performs a copying collection: it traverses reachable objects from the roots, marks them, copies the unmarked objects to to‑space, then swaps the roles of the spaces.

If an object survives the young‑generation collection, it may be promoted to the old generation, especially if it is large (exceeds 25% of to‑space) or survives multiple cycles.

The old generation employs a mark‑sweep/mark‑compact algorithm. During the marking phase, V8 uses a tri‑color marking scheme (white for unreachable, gray for reachable but not yet processed, black for fully processed) and stores the marking state in a bitmap per memory page.

After marking, the collector removes unreachable objects, which can leave fragmented free space. If a large object cannot fit, a full GC is triggered, which may also perform a compaction step that moves live objects to one end of the memory region, freeing a contiguous block.

To avoid scanning the entire old generation when a young‑generation object is referenced from old space, V8 uses a write barrier that records such cross‑generation pointers in a buffer, allowing the collector to quickly locate them.

The article also mentions the stop‑the‑world pause required during full collections, which can cause noticeable UI lag, especially for large old‑generation collections.

V8 mitigates pause times with three techniques: incremental marking (splitting the marking work into short slices), parallel collection (using auxiliary threads to perform the sweep phase), and concurrent collection (running parts of the GC while the JavaScript thread continues, protected by the write barrier).

In conclusion, V8 employs many optimizations—such as promotion heuristics, early marking of long‑lived objects, and efficient handling of large objects—to reduce GC overhead and improve performance.

If you find this content helpful, consider clicking "Watch" to increase its visibility and follow the "Zhengcai Cloud Frontend Team" public account for more articles.

For recruitment, the Zhengcai Cloud Frontend Team (ZooTeam) in Hangzhou is hiring; interested candidates can email [email protected] .