JavaScript Garbage Collection Complete Guide

A complete guide to JavaScript garbage collection. Covers reachability, mark-and-sweep, reference counting, generational collection, memory lifecycle, WeakRef, FinalizationRegistry, common GC pitfalls, and how GC interacts with closures, event loops, and DOM references.

JavaScriptadvanced
17 min read

JavaScript automatically manages memory through garbage collection (GC). The engine allocates memory when objects are created and reclaims it when objects become unreachable. Understanding how GC works helps you write code that avoids memory leaks and interacts efficiently with the memory system.

For the V8-specific implementation, see How V8 Garbage Collector Works in JavaScript.

Memory Lifecycle

Every value in JavaScript goes through three phases:

javascriptjavascript
// 1. ALLOCATION: Engine allocates memory
const user = { name: "Alice", scores: [95, 87, 92] }; // Object + array allocated
const greeting = "Hello, world!";                       // String allocated
const buffer = new ArrayBuffer(1024);                   // 1KB buffer allocated
 
// 2. USE: Read and write the values
console.log(user.name);
user.scores.push(88);
 
// 3. RELEASE: When no references remain, GC reclaims memory
// (happens automatically when objects become unreachable)
PhaseWhat HappensWho Controls It
AllocationMemory reserved for the valueEngine (automatic)
UseValue is read, written, passed aroundYour code
ReleaseMemory returned to the systemGarbage collector (automatic)

Reachability

The core concept of GC is reachability. An object is reachable if it can be accessed from a root through any chain of references:

javascriptjavascript
// Roots: global object, current call stack, active closures
 
// Reachable: connected to a root
let data = { value: 42 };     // root -> data
let ref = data;                // root -> data (two paths)
 
// Still reachable after removing one reference
data = null;                   // ref still points to the object
 
// Unreachable: no path from any root
ref = null;                    // Object { value: 42 } is now unreachable
// GC will reclaim it
 
// Circular references: still collected if unreachable from roots
function createCycle() {
  const a = {};
  const b = {};
  a.ref = b;
  b.ref = a;
  // When this function returns, both a and b are unreachable
  // Modern GC handles circular references correctly
}
 
createCycle(); // Both objects will be collected

Mark-and-Sweep Algorithm

Modern JavaScript engines use mark-and-sweep as the foundational GC algorithm:

javascriptjavascript
// Conceptual illustration of mark-and-sweep
 
function markAndSweep(roots, heap) {
  // MARK PHASE: Start from roots, mark everything reachable
  const marked = new Set();
 
  function mark(obj) {
    if (!obj || marked.has(obj)) return;
    marked.add(obj);
 
    // Traverse all references from this object
    for (const ref of getReferences(obj)) {
      mark(ref);
    }
  }
 
  // Mark from every root
  for (const root of roots) {
    mark(root);
  }
 
  // SWEEP PHASE: Free everything not marked
  for (const obj of heap) {
    if (!marked.has(obj)) {
      free(obj); // Reclaim memory
    }
  }
}
 
// Roots include:
// - Global variables (window, globalThis)
// - Local variables in the current call stack
// - Closures referenced by active functions
// - DOM elements in the document tree
// - Active timers (setTimeout/setInterval callbacks)
// - Promise callbacks in the microtask queue

Reference Counting vs Mark-and-Sweep

FeatureReference CountingMark-and-Sweep
MechanismCount references to each objectTrace reachable objects from roots
Circular referencesCannot collect (leak)Collected when unreachable from roots
Collection timingImmediate when count hits 0Periodic or triggered by allocation
OverheadPer-reference increment/decrementPause during mark phase
Used in JS enginesLegacy (IE6)All modern engines
javascriptjavascript
// Reference counting FAILS with circular references
function referenceCounting() {
  const a = { name: "A" }; // refCount: 1
  const b = { name: "B" }; // refCount: 1
 
  a.partner = b; // b refCount: 2
  b.partner = a; // a refCount: 2
 
  // Remove external references
  // a refCount: 1 (b.partner still points to it)
  // b refCount: 1 (a.partner still points to it)
  // Neither reaches 0 -> LEAK in reference counting
  // Mark-and-sweep handles this correctly
}

Generational Collection

Modern engines divide the heap into generations based on object age:

javascriptjavascript
// Young Generation (Nursery/New Space)
// - Newly created objects land here
// - Collected frequently with a fast "scavenge" algorithm
// - Most objects die young (90%+)
 
function processRequest(data) {
  const temp = data.map((x) => x * 2);    // Short-lived: young gen
  const result = temp.reduce((a, b) => a + b, 0);
  return result;
  // `temp` array becomes unreachable, collected in next young gen GC
}
 
// Old Generation (Old Space/Tenured Space)
// - Objects that survive multiple young gen collections are "promoted"
// - Collected less frequently with full mark-and-sweep
// - Contains long-lived objects: caches, configurations, singleton instances
 
const appConfig = {             // Long-lived: promoted to old gen
  theme: "dark",
  language: "en",
  features: ["search", "notifications"],
};
 
// This matters for performance:
// - Avoid creating many long-lived temporary objects
// - Short-lived objects are cheap (young gen collection is fast)
// - Old gen collection (major GC) causes longer pauses

WeakRef and FinalizationRegistry

These APIs let you interact with GC behavior without preventing collection:

javascriptjavascript
// WeakRef: a reference that does not prevent GC
class ImageCache {
  constructor() {
    this.cache = new Map();
  }
 
  set(url, imageData) {
    this.cache.set(url, new WeakRef(imageData));
  }
 
  get(url) {
    const ref = this.cache.get(url);
    if (!ref) return null;
 
    const data = ref.deref();
    if (data === undefined) {
      // Object was garbage collected
      this.cache.delete(url);
      return null;
    }
 
    return data;
  }
}
 
// FinalizationRegistry: run cleanup when objects are collected
const registry = new FinalizationRegistry((metadata) => {
  console.log(`Object collected: ${metadata.label}`);
  // Clean up external resources (file handles, network connections)
  if (metadata.cleanup) {
    metadata.cleanup();
  }
});
 
function createResource(label) {
  const resource = {
    data: new ArrayBuffer(1024 * 1024),
    label,
  };
 
  registry.register(resource, {
    label,
    cleanup: () => console.log(`Cleanup for ${label}`),
  });
 
  return resource;
}
 
let res = createResource("buffer-1");
res = null; // After GC runs, FinalizationRegistry callback fires

GC and Closures

javascriptjavascript
// Closures retain their entire scope chain
function outer() {
  const largeArray = new Array(1000000).fill("data");
  const smallValue = 42;
 
  // This closure captures the entire scope of `outer`
  // Both `largeArray` AND `smallValue` are retained
  return function inner() {
    return smallValue;
  };
}
 
const fn = outer();
// `largeArray` is retained even though `inner` only uses `smallValue`
// (Some engines optimize this, but it is not guaranteed)
 
// Best practice: extract only needed values
function outerOptimized() {
  const largeArray = new Array(1000000).fill("data");
  const smallValue = computeResult(largeArray);
 
  // `largeArray` is not referenced by the returned function
  return function inner() {
    return smallValue;
  };
}

GC and the Event Loop

javascriptjavascript
// GC pauses happen between event loop tasks
// The engine chooses when to run based on memory pressure
 
// Incremental GC: breaks work into small chunks between tasks
// This reduces noticeable pauses
 
// You can hint that you are idle (though not standard):
if ("requestIdleCallback" in window) {
  requestIdleCallback((deadline) => {
    // Browser may schedule GC during idle periods
    while (deadline.timeRemaining() > 5) {
      processNextItem();
    }
  });
}
 
// Avoid creating pressure: batch allocations instead of scattering them
// BAD: allocates inside a hot loop
function processItemsBad(items) {
  for (const item of items) {
    const temp = { ...item, processed: true }; // New object each iteration
    saveToDB(temp);
  }
}
 
// BETTER: reuse or pre-allocate
function processItemsBetter(items) {
  const temp = {};
 
  for (const item of items) {
    Object.assign(temp, item);
    temp.processed = true;
    saveToDB(temp);
    // Clear for next iteration
    for (const key of Object.keys(temp)) {
      delete temp[key];
    }
  }
}

GC Performance Tips

TipReason
Avoid creating objects in hot loopsReduces young generation pressure and scavenge frequency
Null out references when doneMakes objects unreachable sooner for collection
Use object pools for frequent allocationsReuses memory instead of allocating/collecting repeatedly
Prefer flat data structuresFewer references to trace during mark phase
Use WeakMap for DOM-keyed cachesAutomatically cleans up when DOM elements are removed
Avoid closures over large scopesPrevents unintentional retention of large objects
Rune AI

Rune AI

Key Insights

  • Reachability determines collection: An object is only collected when no reference chain connects it to a root (globals, stack, active closures, DOM tree)
  • Mark-and-sweep handles circular references: Unlike reference counting, tracing GC correctly collects mutually-referencing objects that are unreachable from roots
  • Generational GC optimizes for short-lived objects: Most objects die young, so frequent young-generation collection is fast and efficient while old-generation collection is less frequent
  • Closures retain entire scope chains: A returned function may keep large arrays alive even if it only accesses a small value from the same scope
  • WeakRef and FinalizationRegistry cooperate with GC: Use WeakRef for caches that should not prevent collection, and FinalizationRegistry for cleanup callbacks when objects are finally collected
RunePowered by Rune AI

Frequently Asked Questions

Does JavaScript have manual memory management?

No. JavaScript does not provide `malloc`, `free`, or explicit deallocation. The garbage collector handles all memory reclamation. However, you control when objects become unreachable by managing references, which is why understanding GC is important for avoiding leaks. See [Fixing JavaScript Memory Leaks: Complete Guide](/tutorials/programming-languages/javascript/fixing-javascript-memory-leaks-complete-guide) for practical patterns.

How often does garbage collection run?

The engine decides based on memory pressure, allocation rate, and idle time. Young generation collection runs frequently (every few milliseconds under pressure). Old generation collection runs less often. You cannot trigger GC from application code (except in Node.js with the `--expose-gc` flag for debugging).

Do modern engines still use reference counting?

Modern engines (V8, SpiderMonkey, JavaScriptCore) use tracing GC (mark-and-sweep with generational optimization), not reference counting. Reference counting was used in older engines like IE6's JScript. Tracing GC correctly handles circular references, which reference counting cannot.

Does setting a variable to null immediately free memory?

No. It makes the object potentially unreachable, but the garbage collector runs on its own schedule. The memory is reclaimed during the next GC cycle that processes the relevant generation. Setting to `null` is still the correct practice because it enables future collection.

What is the difference between minor GC and major GC?

Minor GC (scavenge) collects the young generation only. It is fast (sub-millisecond to a few milliseconds) and happens frequently. Major GC (mark-sweep-compact) collects the entire heap including old generation. It takes longer (10-100ms+) and happens less frequently. See [How V8 Garbage Collector Works](/tutorials/programming-languages/javascript/how-v8-garbage-collector-works-in-javascript) for engine-specific details.

Conclusion

JavaScript garbage collection uses reachability-based tracing with mark-and-sweep to automatically reclaim memory. Modern engines use generational collection where short-lived objects are collected quickly and long-lived objects are promoted to old space. Write GC-friendly code by minimizing allocations in hot paths, nulling references early, using object pools, and leveraging WeakRef/WeakMap for caches. For V8-specific internals, see How V8 Garbage Collector Works. For the mark-and-sweep algorithm in depth, see Mark-and-Sweep Algorithm in JS.