How does garbage collection work in JavaScript?

JavaScript has automatic memory management: you never free an object, the engine does it once the object is unreachable. The collector starts from a set of roots (the call stack's live variables, the global object, and engine-internal handles) and follows every reference. Objects it reaches are live; the rest are garbage and their memory is reused.

The standard algorithm is mark-and-sweep (V8 adds compaction):

1. Mark. Traverse the object graph from the roots and mark everything reached.
2. Sweep. Reclaim every unmarked object.
3. Compact (optional). Move survivors together to reduce fragmentation.

The alternative, reference counting ("free when nothing points to it"), fails on cycles: two objects that reference each other both keep a count of 1 forever, even when nothing else can reach them. MDN says no modern JavaScript engine uses it. Tracing handles cycles for free, because reachability is measured from the roots, not from counts.

Three things interviewers want to hear:

• Reachability, not usefulness. The collector cannot know that you will never read an object again, only that you cannot. A forgotten reference in a cache, listener or closure is still a reference. That is every JavaScript memory leak.
• No guarantees. The spec (in the WeakRef section) says it "does not make any guarantees that any object or symbol will be garbage collected." Objects may be released "after long periods of time, or never at all." Timing is invisible to your code by design.
• You cannot trigger it. There is no standard gc(). V8 exposes one only behind --expose-gc, which is for experiments and tests.

// gc-cycle.mjs, run with: node --expose-gc gc-cycle.mjs
const heapMB = () => {
  global.gc(); // collect first so heapUsed reflects live objects only
  return Math.round(process.memoryUsage().heapUsed / 1024 / 1024);
};

const baseline = heapMB();
let pairs = [];
for (let i = 0; i < 500_000; i++) {
  const a = { payload: new Array(8).fill(i) };
  const b = { a };
  a.b = b; // cycle: reference counting could never free this pair
  pairs.push(a);
}
const held = heapMB();
console.log(pairs.length); // → 500000 (also keeps `pairs` in use)
pairs = null;              // the only path from a root is gone
const collected = heapMB();
console.log({ baseline, held, collected });
// → { baseline: 3, held: 111, collected: 4 }

The MB figures are one machine, Node 24.19, macOS, run 3 times with the same result. Yours will differ; the shape (grow, then fall back once unreachable) is the point.

• Saying "an object is freed when nothing references it" and stopping there. That describes reference counting. The accurate wording is "when it is not reachable from a root", which is why cycles do not leak.
• Treating x = null as "freeing" memory. It only removes one reference; the object survives if anything else still reaches it, and it is reclaimed at the engine's convenience, not immediately.
• Reading process.memoryUsage().heapUsed without forcing a collection and drawing conclusions. Between collections it includes garbage, so it rises and falls. Compare readings only after global.gc() (under --expose-gc), or look at the trend over a long run.
• Calling global.gc() in production code. It is a measurement tool; forcing full collections hurts latency.