Vocabulary for Memory Leaks and Garbage Collection

Memory problems are among the hardest bugs to explain clearly, partly because the vocabulary is genuinely confusing at first — “leak” in a garbage-collected language doesn’t mean what it means in a language with manual memory management. Getting this vocabulary precise helps enormously when writing up an incident, requesting a heap dump from a teammate, or explaining to a non-specialist why a service’s memory usage keeps climbing.

Foundational Concepts

1. Memory leak

Memory that a program has allocated but no longer needs, yet fails to release, causing memory usage to grow over time without bound.

Usage: “This service’s memory climbs steadily under sustained traffic and never comes back down — that’s a strong signal of a memory leak somewhere in the request path.”

2. Garbage collection (GC)

The automated process by which a managed-memory runtime identifies and reclaims memory that’s no longer reachable from the program, removing the need for manual deallocation.

Usage: “Even with garbage collection handling deallocation for us, we can still leak memory — it just means something is holding an unintended reference, not a raw pointer being forgotten.”

3. Reachability

The property of an object still being accessible from some root reference (like a global variable or an active stack frame), which garbage collectors use to determine what’s eligible for collection.

Usage: “This cache entry is technically still reachable through a static reference, so the garbage collector correctly leaves it alone — the leak is that nothing ever removes it from the cache.”

4. GC pause (stop-the-world pause)

A period during which a garbage collector suspends some or all of a program’s execution to safely reclaim memory, which can cause visible latency spikes.

Usage: “We saw a 400-millisecond GC pause right before that request timeout — the pause itself, not application logic, is likely the actual cause of the slow response.”

5. Heap

The region of memory where a program’s dynamically allocated objects live, as opposed to the stack, which holds short-lived function-local data.

Usage: “Heap usage keeps growing across GC cycles instead of returning to baseline, which is the clearest sign that we’re actually leaking rather than just seeing normal allocation churn.”

Diagnosis Vocabulary

6. Heap dump

A snapshot of everything currently allocated on the heap at a given moment, used to analyze what’s consuming memory and trace unexpected retention back to its source.

Usage: “Can you grab a heap dump the next time memory usage crosses the alert threshold? That’ll let us see exactly what’s accumulating instead of guessing.”

7. Retained size

The total amount of memory that would be freed if a specific object were garbage collected, including everything it exclusively keeps alive — a key metric for finding the real source of a leak.

Usage: “This object’s shallow size is tiny, but its retained size is enormous because it’s the only thing keeping an entire cached dataset reachable.”

8. Dominator (in a heap graph)

An object that lies on every path from the root to another object, meaning collecting the dominator would also make the dominated object unreachable — used to trace retention chains back to a root cause.

Usage: “Tracing the dominator chain led us straight back to a single event listener that was never removed, which was keeping this entire subtree alive.”

9. Reference leak

A specific pattern in garbage-collected languages where an unintended reference — like an entry in a cache, a subscribed listener, or a closure — keeps an object reachable long after it’s actually needed.

Usage: “This isn’t a raw memory bug — it’s a reference leak, where an event listener registered on page load never gets removed, so the component it references can never be collected.”

10. Memory churn

The rate at which short-lived objects are allocated and subsequently collected, which can cause performance overhead through frequent GC cycles even without any actual leak.

Usage: “We’re not leaking here — this is memory churn from allocating a new object per request in a hot loop, and it’s triggering GC far more often than necessary.”

Common Causes

11. Closure capture

A situation where a closure unintentionally retains a reference to a large object from its enclosing scope, keeping that object alive as long as the closure itself is reachable.

Usage: “This closure only needs one field from the enclosing object, but it captured the whole thing, so the entire object stays alive as long as this callback is registered.”

12. Detached DOM node

A DOM element that has been removed from the visible page but is still referenced by JavaScript, preventing the browser from reclaiming the memory it occupies.

Usage: “The heap snapshot shows thousands of detached DOM nodes — we removed these elements from the page but never cleared the references our code was still holding to them.”

13. Listener leak

A memory leak caused specifically by event listeners or subscriptions that are registered but never unregistered, keeping the objects they reference alive indefinitely.

Usage: “Every time this modal opens, it adds a new listener to the window object but never removes the old one on close — that’s a listener leak that compounds with each open.”

14. Unbounded cache

A cache with no eviction policy or size limit, which will grow indefinitely and functionally behave like a memory leak even though the retention is technically intentional.

Usage: “Technically nothing here is a bug — it’s an unbounded cache that was never given an eviction policy, so it just keeps growing until it exhausts available memory.”

15. Generational hypothesis

The observation, underlying many garbage collectors’ designs, that most objects die young, which justifies collecting recently-allocated objects (the young generation) more frequently than older ones.

Usage: “This collector is tuned around the generational hypothesis, so most short-lived request objects get collected cheaply in the young generation, and only long-lived objects pay the cost of promotion.”

Key Takeaways

• Understand that a memory leak in a garbage-collected language is a reference leak, not a forgotten deallocation — something is unintentionally keeping an object reachable.
• Use retained size and dominator vocabulary when analyzing a heap dump, since shallow size alone often misleads about where memory is actually going.
• Distinguish an actual leak (unbounded growth over time) from memory churn (frequent allocation and collection without net growth) before proposing a fix.
• Name common leak patterns specifically — listener leaks, closure capture, unbounded caches, detached DOM nodes — rather than describing memory problems only vaguely.
• Explain GC pauses as a specific latency cause distinct from application logic when a slow request coincides with one, since the fix (GC tuning) is entirely different from an application-level optimization.