How Mark-and-Sweep Garbage Collection Works

Mark-and-sweep remains the foundational tracing algorithm for modern JavaScript runtimes. Unlike legacy reference counting strategies, it eliminates cyclic reference leaks by periodically traversing the object graph from known roots. For engineers diagnosing memory pressure, understanding this mechanism is essential to interpreting JavaScript Memory Fundamentals & Runtime Mechanics and optimizing long-running applications. This guide details the algorithmic phases, heap traversal logic, and profiling workflows required to verify successful JS memory reclamation.

The Algorithmic Phases: Mark and Sweep #

The process operates in two distinct, deterministic phases. During the mark phase, the V8 garbage collection engine identifies all reachable objects starting from global roots, execution contexts, and active stack frames. Because Stack vs Heap Memory Allocation in JavaScript dictates where references originate, the collector traces pointers from stack-allocated variables and CPU registers directly into the heap. Each visited object receives a mark bit. Objects that remain unmarked are deemed unreachable.

The sweep phase then iterates through the allocated memory space, reclaiming bytes from unmarked slots and updating free-list pointers for subsequent allocations. This traversal-based approach inherently resolves circular references, as isolated cycles without a path to a root remain unmarked and are safely collected.

V8 Implementation & Generational Optimization #

V8 optimizes the traditional mark-and-sweep algorithm through generational collection, leveraging the weak generational hypothesis. Short-lived objects reside in the young generation, collected via a fast, copying variant known as Scavenger. Long-lived objects that survive multiple cycles migrate to the old generation, where full mark-and-sweep cycles occur less frequently. Engineers analyzing Understanding the V8 Heap Layout and Memory Segments will observe distinct space boundaries (NewSpace, OldSpace, LargeObjectSpace) that dictate collection triggers.

The algorithm’s efficiency relies on write barriers and remembered sets to track cross-generational pointers, avoiding full-graph traversal on every minor cycle. To observe these cycles in real-time, developers can launch Node.js or Chromium with --trace-gc, which logs minor/major GC events, pause times, and reclaimed memory sizes directly to the console. For memory-constrained environments, --max-old-space-size can be tuned to cap heap growth and force earlier major collection cycles.

Heap Fragmentation & Compaction Trade-offs #

As the sweep phase reclaims scattered memory blocks, the heap inevitably develops non-contiguous free regions. While modern V8 employs incremental and concurrent marking to reduce main-thread stalls, it must balance compaction overhead against allocation speed. Repeated large allocations followed by partial deallocations directly impact What causes memory fragmentation in V8 engine, forcing the runtime to trigger expensive compaction passes or prematurely escalate to out-of-memory conditions. In high-throughput environments, administrators may adjust --compaction-interval or --max-semi-space-size to mitigate allocation latency, though this trades CPU overhead for improved memory locality.

Profiling Workflows & DevTools Verification #

Verifying successful reclamation requires a structured heap snapshot analysis workflow. Follow these steps in Chrome DevTools or Node.js Inspector:

1. Establish a baseline: Open the Memory panel, select “Heap snapshot,” and capture an initial snapshot before executing the target workload. Record the baseline Total heap size and Used heap size.
2. Trigger deterministic allocation: Execute the suspected memory-intensive function, component lifecycle, or data-fetching routine.
3. Force garbage collection: In Node.js, run with --expose-gc and call global.gc(). In DevTools, click the trash can icon (“Collect garbage”) to ensure synchronous reclamation.
4. Capture delta snapshot: Take a second heap snapshot immediately after GC completes.
5. Analyze retained sizes: Switch to the “Comparison” view in DevTools. Filter by constructor or class name. Verify that the # Delta and Size Delta columns approach zero for objects expected to be released. A persistent positive delta indicates retained references.
6. Validate root paths: Expand any retained objects to inspect the “Retainers” pane. Trace the exact reference chain preventing collection, focusing on closures, event listeners, or detached DOM nodes.

Framework-Specific Memory Patterns & Common Mistakes #

Modern frameworks introduce specific retention patterns that interact with the tracing garbage collector. React’s fiber architecture, Vue’s reactivity proxies, and Angular’s zone.js can inadvertently maintain strong references if cleanup hooks (useEffect return functions, onUnmounted, ngOnDestroy) fail to detach listeners or clear intervals. Avoid these common pitfalls:

• Assuming automatic collection is instantaneous: V8 schedules GC asynchronously based on allocation rate and heap thresholds, not reference count.
• Ignoring closure scope retention: Inner functions capture outer lexical environments. If an event handler or framework lifecycle hook fails to detach, parent objects remain marked as reachable.
• Misinterpreting heap snapshots: Failing to use the “Comparison” view leads to false positives from internal runtime caches, hidden classes, and V8’s inline caches.
• Overusing WeakMap/WeakRef without fallbacks: Weak references do not prevent collection, but improper cache eviction logic can cause thrashing during mark phases, increasing CPU overhead and delaying sweep completion.

Code Example: Verifying Mark-and-Sweep Reclamation in Node.js #

The following script demonstrates explicit reference detachment followed by forced GC invocation. The memory delta validates that the tracing collector successfully identified the unreachable array during the sweep phase and returned the space to the allocator.

// Run with: node --expose-gc --trace-gc verify_gc.js
const initial = process.memoryUsage().heapUsed;
console.log(`Baseline heapUsed: ${initial} bytes`);

// Allocate ~8MB of object references
let largeArray = new Array(1e6).fill({ id: 'alloc', payload: new Uint8Array(8) });
console.log(`Post-allocation heapUsed: ${process.memoryUsage().heapUsed} bytes`);

// Detach reference to make objects unreachable
largeArray = null;

// Force major GC cycle
global.gc();

const final = process.memoryUsage().heapUsed;
console.log(`Post-GC heapUsed: ${final} bytes`);
console.log(`Reclamation Delta: ${final - initial} bytes`);
// A delta near 0–500 bytes confirms successful mark-and-sweep reclamation.
// Higher deltas indicate retained references or V8 internal metadata overhead.

Frequently Asked Questions #

How does mark-and-sweep handle circular references in JavaScript? #

Unlike reference counting, mark-and-sweep starts from GC roots and traverses only reachable objects. Circular references that are not reachable from any root remain unmarked and are safely collected during the sweep phase.

Why does heap usage sometimes increase immediately after forcing garbage collection? #

V8 may trigger compaction or internal metadata allocation during major GC cycles. Additionally, the runtime might pre-allocate memory for upcoming operations. Always compare retained sizes across multiple snapshots rather than relying on instantaneous process.memoryUsage() readings.

Can developers manually control the mark-and-sweep cycle in browsers? #

No. Browser environments intentionally hide GC internals to prevent timing attacks and optimize user experience. Developers should focus on eliminating strong reference chains and using DevTools heap profiling to verify reclamation.