Generational collection & the Scavenger

Why objects die young

JavaScript programs create many small, temporary objects. A formatted message, an event payload, or an object literal inside a function often becomes unreachable before the next screen update. Engines exploit that common pattern instead of treating every object as equally likely to live for hours.

This continues Mark-sweep & mark-compact. That lesson explains how a collector finds live objects. This lesson asks a simpler question first: where should it spend that work?

The generational hypothesis

The generational hypothesis is the observed pattern that most newly allocated objects become unreachable soon. It is a useful tendency, not a JavaScript guarantee. A cart can be long-lived; a message created while adding tea is usually short-lived.

1const cart = [];2 3function addTea() {4  const message = { item: "tea", qty: 1 };5  cart.push("tea");6  return message.item;7}8 9console.log(addTea());10console.log(cart.length);

Line 1 creates cart outside the function, so it can stay reachable for the shopping session. Line 4 creates message. Line 6 returns only its item text, so the message object can die when addTea returns. The code prints tea, then 1.

The word most matters. The engine does not know that a receipt is unimportant just because it has that name. It learns only from reachability and from the repeated pattern that many new values disappear before the next young collection.

1function makeReceipts(times) {2  let diedYoung = 0;3  for (let index = 0; index < times; index += 1) {4    const receipt = { item: "tea", index };5    diedYoung += receipt.item === "tea" ? 1 : 0;6  }7  return diedYoung;8}9 10console.log(makeReceipts(3));

Line 1 accepts the number of receipt-making turns. Line 3 makes one small receipt each turn. Line 5 counts it as a young death in this teaching model, and line 9 prints 3. This is a model count, not a browser heap measurement.

Young and old generations

The young generation is the small area for new allocations. It is collected often because most objects there die quickly. The old generation holds objects that already survived young collections, so it is not scanned for every small burst of temporary work.

1const youngSpace = ["message", "receipt"];2const oldSpace = ["cart"];3 4console.log("young " + youngSpace.length);5console.log("old " + oldSpace.length);

Line 1 puts temporary names in the young-space array. Line 2 puts the durable cart in old space. Lines 4 and 5 print young 2 and old 1. The arrays are labels for a teaching model; JavaScript arrays do not choose a real heap generation.

The split is a cost decision. A frequent young collection can inspect a small area and leave a large, stable cart or app state alone. A small young space is cheap to clean because dead values are skipped and the few live values are copied.

This does not change JavaScript reachability. A young object can be live, and an old object can later be garbage. Age decides which collection usually looks first; root paths decide whether the object survives.

Semi-space copying and Cheney's algorithm

Semi-space copying reserves two young halves: from-space contains current objects and to-space receives survivors. Rather than freeing each dead message, the collector copies reachable survivors and discards the entire old half in one go.

1const roots = ["cart"];Run2const fromSpace = [3  { id: "cart", age: 0, children: ["tea"] },4  { id: "tea", age: 0, children: [] },5  { id: "message", age: 0, children: [] },6];7 8function scavenge(roots, fromSpace, oldSpace = []) {9  const byId = new Map(fromSpace.map((item) => [item.id, item]));10  const toSpace = [];11  let scan = 0;12  for (const id of roots) copy(id);13  while (scan < toSpace.length) {14    for (const child of toSpace[scan].children) copy(child);15    scan += 1;16  }17  function copy(id) {18    const item = byId.get(id);19    if (!item || toSpace.some((copy) => copy.id === id)) return;20    const next = { ...item, age: item.age + 1 };21    if (next.age >= 2) oldSpace.push(next); else toSpace.push(next);22  }23  return { fromSpace: [], toSpace, oldSpace };24}25 26console.log(scavenge(roots, fromSpace).toSpace.map((item) => item.id).join(","));

Cheney's algorithm is a simple breadth-first copying plan. It keeps a scan index over objects already copied to to-space. Each scanned survivor can reveal children that also need copying. The model increments age as it copies.

1const fromSpace = [2  { id: "cart", child: "tea" },3  { id: "tea", child: null },4];5const forwarding = new Map();6 7function copyOnce(id) {8  if (forwarding.has(id)) return forwarding.get(id);9  const address = "to-" + forwarding.size;10  forwarding.set(id, address);11  return address;12}13 14console.log(copyOnce("cart"));15console.log(copyOnce("cart"));

Line 5 creates a forwarding map. Line 8 checks whether cart already has a to-space address. Line 9 makes an address only on the first copy. Lines 13 and 14 both print to-0, which shows why two references to one object do not create two copies.

The scan index is what makes the work breadth-first. First copy roots. Then scan the first copied object, copy its children, advance scan, and repeat until every copied object has been scanned. At that point every reachable young object is in the destination half.

1const roots = ["cart"];2const fromSpace = [3  { id: "cart", age: 0, children: ["tea"] },4  { id: "tea", age: 0, children: [] },5  { id: "message", age: 0, children: [] },6];7 8function scavenge(roots, fromSpace, oldSpace = []) {9  const byId = new Map(fromSpace.map((item) => [item.id, item]));10  const toSpace = [];11  let scan = 0;12  for (const id of roots) copy(id);13  while (scan < toSpace.length) {14    for (const child of toSpace[scan].children) copy(child);15    scan += 1;16  }17  function copy(id) {18    const item = byId.get(id);19    if (!item || toSpace.some((copy) => copy.id === id)) return;20    const next = { ...item, age: item.age + 1 };21    if (next.age >= 2) oldSpace.push(next); else toSpace.push(next);22  }23  return { fromSpace: [], toSpace, oldSpace };24}25 26console.log(scavenge(roots, fromSpace).toSpace.map((item) => item.id).join(","));

Promotion, tenuring, and pretenuring

Tenuring means tracking how many young collections an object survives. In this teaching model, an object moves to old space after its second survival. Real engines choose details differently, but the reason is the same: repeatedly copying a durable cart wastes young-collection work.

1const survivor = { id: "cart", age: 1 };2survivor.age += 1;3const destination = survivor.age >= 2 ? "old space" : "to-space";4 5console.log(destination);6console.log(survivor.age);

Line 1 starts a cart at age 1. Line 2 records one more survival. Line 3 chooses old space because age is now two. Lines 5 and 6 print old space and 2.

Pretenuring means an engine may notice that one allocation site usually creates long-lived objects and allocate those objects directly in old space. For example, a site that builds the persistent cart state for every session may be a better old-space candidate than a receipt created for one click.

1function chooseSpace(survivesOften) {2  return survivesOften ? "old space" : "young space";3}4 5console.log(chooseSpace(true));6console.log(chooseSpace(false));

Line 1 asks one clear question about an allocation site. Line 2 returns old space when its objects usually survive. Lines 5 and 6 print old space and young space.

Pretenuring is not an API and it is not a promise. Application code should still make ownership clear, remove accidental retainers, and measure before changing allocation patterns. The engine can revise its allocation choice when the program changes.

Parallel mark-evacuate

Parallel scavenging lets several helper threads copy survivors at the same time when the engine can do so safely. V8 can use parallel mark-evacuate work too. The point is shared work, not a promise about one fixed number of threads.

1const survivors = ["cart", "tea", "user", "note"];2const helpers = [[], []];3 4for (const [index, id] of survivors.entries()) {5  helpers[index % helpers.length].push(id);6}7 8console.log(helpers[0].join(","));9console.log(helpers[1].join(","));

Line 1 names four survivors. Line 2 makes two work lists. Lines 4 and 5 give alternating names to the two lists. Lines 8 and 9 print cart,user and tea,note. This is a sequential JavaScript model of divided work, not a thread-count probe.

Real helpers need shared coordination. They must claim a survivor before copying it, publish its forwarding address, and keep checking for more work. That extra machinery prevents two helpers from moving the same object twice.

Parallel work can reduce elapsed collection time when enough survivors exist. It does not erase all pause costs, and it can add coordination overhead when the young collection is tiny.

Minor and major collections

A minor collection touches the young generation only. V8 calls this a Scavenge. It is frequent and usually fast because the young area is deliberately small and most objects are not copied.

1const events = ["minor", "minor", "minor", "major", "minor"];2const counts = { minor: 0, major: 0 };3 4for (const event of events) {5  counts[event] += 1;6}7 8console.log("minor " + counts.minor);9console.log("major " + counts.major);

Line 1 contains four minor events and one major event. Line 5 increases the matching counter. Lines 8 and 9 print minor 4 and major 1.

1const events = ["minor", "minor", "minor", "major", "minor"];Run2const counts = { minor: 0, major: 0 };3 4for (const event of events) {5  counts[event] += 1;6}7 8console.log("minor " + counts.minor);9console.log("major " + counts.major);

Small V8 evidence

Node exposes V8 information for diagnosis. These snippets are Node-only, so they are not browser playgrounds. The lesson test asserts names and version families only; it never treats heap sizes or timings as stable facts.

import v8 from "node:v8";
console.log(process.version);
console.log(process.versions.v8);
console.log(v8.getHeapSpaceStatistics().map((space) => space.space_name).join(","));

const keep = [];
for (let index = 0; index < 30000; index += 1) {
  keep.push({ item: "tea", index });
}
console.log("kept", keep.length);

On Node 22 with V8 12.4, heap statistics include new_space and old_space. Running the second snippet with --trace-gc prints Scavenge lines. Those words are evidence of the concepts, not performance promises.

Practical allocation habits

Do not write app code around one assumed collection schedule. Keep temporary values local, avoid accidental global caches, and remove listeners or timers that retain data. A long-lived object is fine when it belongs to a clear owner.

Common misconceptions

• “Young means unreachable.” Young means recently allocated. A young object can be live.
• “Promotion means permanent.” Old objects can still become garbage and be collected later.
• “Minor means no moving.” A copying Scavenge moves survivors.
• “Pretenuring is an API.” It is an engine choice based on observed allocation behavior.

Practice exercises

const cart = ["tea"];
function makeMessage() {
  const message = { item: "tea", qty: 1 };
  return message.item;
}
console.log(makeMessage());
console.log(cart.length);

const result = scavenge(["cart"], [
  { id: "cart", age: 0, children: [] },
  { id: "message", age: 0, children: [] },
]);
console.log(result.toSpace.map((item) => item.id).join(","));

Check your understanding

Use the cart, message, and two-space model to keep the terms separate.

Key takeaways

• Most new objects die young, so engines collect young space often.
• Semi-space copying moves survivors and discards the whole old half.
• Survivors may be promoted to old space; pretenuring can skip young space for likely durable objects.
• Minor Scavenge work is young-only; major Mark-Compact work can cover the heap.

Coming next: Write barriers & remembered sets, where old objects point to young ones.