Garbage collection and memory leaks

The back office closes a dormant account only when no chain of links from an active customer or a live standing order still reaches it.

In the analogy	In the system
Active customers, and standing orders the bank's own scheduler runs	Roots (globals, stack, live timers)
The clerk starts at each active customer and follows every linked account, mandate and sub-account, flagging each	Mark: transitive reachability
Unflagged accounts are closed, whether anyone still "wants" them or not	Sweep: reachability decides, not usefulness
A direct-debit mandate on an active account, never cancelled, that still links an old escrow account. Close the active account and its mandates go with it	A listener on a reachable emitter keeps its closure's data. The listener is not a root
A standing order the scheduler keeps paying into an old account	A live setInterval roots its callback
A "keep on file" register that clerks only ever add to	A Map cache with no delete
A note "if account 7 is still open, use it", which puts no hold on it	WeakRef / WeakMap key

Breaks down when:

• The back office closes accounts at a posted end-of-day run. GC timing is the engine's choice, so never infer "collected" from elapsed time.
• A dormant account costs fees that someone notices, and the bank writes to the customer first. A leak is silent, and the collector asks no one.

Contrasting case: reference counting. A strategy that frees an object when its count of incoming references reaches 0 never frees two objects that point at each other, even when nothing else reaches them. Mark-and-sweep does free them, because it asks only "reachable from a root?".

In real terms: the collector frees what no root can reach, and a leak is an unwanted path from a root.

Example 1: ExamHall, EXH-361 and the MR !719 fix. Each reconnect adds an alert listener and a 60 s heartbeat setInterval, and both callbacks close over the tile's frame buffer. Three strategies, three connections each, then one alert. File: e1-reconnect.mjs, excerpt:

function connect(candidateId) {
  if (current) {
    if (abortListener) current.controller.abort();           // removes the { signal } listener
    if (clearHeartbeat) clearInterval(current.heartbeat);
  }
  const frames = Array.from({ length: 1_000 }, (_, n) => `${candidateId}:${n}`);
  const controller = new AbortController();
  socket.addEventListener('alert', () => { handlerRuns++; frames.push('alert'); }, { signal: controller.signal });
  const heartbeat = setInterval(() => frames.length, 60_000);
  current = { controller, heartbeat, ref: new WeakRef(frames) };
}

leaky        : handler runs per alert 3, intervals 3, old buffers alive 2 of 2
abort only   : handler runs per alert 1, intervals 3, old buffers alive 2 of 2
abort + clear: handler runs per alert 1, intervals 1, old buffers alive 0 of 2

Aborting fixes the triple alert but not the memory, because the intervals still root the old buffers (step 5). The buffers are collected only after both paths are cut. 50 runs + 200 at 8 in parallel: 1 distinct output.

Example 2: catalog, a price-badge cache. 500 products per category page, each with a 1,000-item gallery. One page's badges are cached in a Map, one in a WeakMap, and one in a Map from SKU to WeakRef. Then the shopper leaves all three pages. File: e2-catalog-cache.mjs.

Map: entries 500, first product alive true
WeakMap: first product alive false
Map of WeakRefs: entries 500, products alive 0
WeakMap string key: TypeError: Invalid value used as weak map key

The Map keeps every product, gallery included. The WeakMap lets the products go. The WeakRef values let the products go, but the 500 entries stay: bound the map with an LRU or a FinalizationRegistry cleanup. WeakMap keys must be objects (or non-registered symbols), which is why the string key throws. 50 + 200 runs: 1 distinct output.

Example 3: chat, a detached message node (browser-only). A "recently rendered" array, kept for scroll restore, is pushed to and never trimmed. Two messages render, only msg-1 is remembered, then both leave the list (list.replaceChildren()). File: e3-chat-detached.page.js, run by e3-run-chromium.cjs, with GC forced over CDP (HeapProfiler.collectGarbage, three passes in later tasks).

kept <li>: alive true, isConnected false; dropped <li>: alive false | queryObjects(MessageView): 1

msg-1's <li> is detached: it is out of the document and still in memory, because recentlyRendered → MessageView → node is a path from a root. Headless Chromium 153, 50 fresh contexts: 1 distinct output. This is verified in Chromium only. Firefox and Safari were not run.