Academy — Sanjib Sikder

Memory Is Not Infinite

JavaScript manages memory for you — you never call malloc or free. But "automatic" does not mean "free". The garbage collector can only reclaim memory it can prove is unreachable. If you accidentally keep a reference to something you no longer need, it stays in memory forever. In a long-running application — a Node.js server, a single-page app that runs for hours — this is how you run out of memory and crash.

Start by understanding what reachability means:

JavaScript

Ctrl+Enter to run

// Reachability — the GC's only question: can this object be reached?

let student = { name: "Rahul", marks: 82 };
// student is reachable — the variable holds a reference

let copy = student;
// both 'student' and 'copy' reference the same object — still reachable

student = null;
// 'student' no longer points to the object — but 'copy' still does
// the object is still reachable — NOT collected

copy = null;
// now nothing references the object
// it is unreachable — eligible for garbage collection

console.log("Both references dropped — object eligible for GC");

// Circular references are handled correctly by modern GC
let a = {};
let b = {};
a.other = b;
b.other = a; // circular — but if nothing external references a or b...
a = null;
b = null; // both dropped — GC correctly collects the cycle
console.log("Circular references — also collected when unreachable from root");

The GC starts from roots — global variables, the current call stack, and active closures — and follows every reference. Anything reachable from a root stays. Anything not reachable is collected. Circular references between objects are not a problem as long as the cycle itself is unreachable from a root.

The Generational Heap

V8's heap is split into two main regions based on the observation that most objects die young — allocated in a function, used briefly, then immediately eligible for collection:

New Space (Young Generation)   ~1–8 MB
├── From-space
└── To-space         ← Minor GC (Scavenge) runs here, very fast

Old Space (Old Generation)     ~hundreds of MB
└── Objects that survived 2+ minor GCs live here
    Major GC (Mark-Sweep-Compact) runs here, slower

JavaScript

Ctrl+Enter to run

// Illustrating short-lived vs long-lived allocation patterns

// Short-lived — ideal. Objects born and die inside the function.
// V8's minor GC (Scavenge) handles these cheaply.
function processShortLived(data) {
// These allocations are all short-lived
const filtered = data.filter(x => x > 50);
const mapped = filtered.map(x => ({ value: x, grade: x >= 75 ? "A" : "B" }));
const result = mapped.reduce((acc, { grade }) => {
acc[grade] = (acc[grade] || 0) + 1;
return acc;
}, {});
return result;
}

const scores = Array.from({ length: 1000 }, (_, i) => (i * 37) % 100);
console.log(processShortLived(scores));

// Long-lived — objects that outlive the function they were created in.
// These get promoted to Old Space. GC cost is paid once, then amortised.
const globalCache = new Map(); // lives as long as the program

function getOrCompute(key, fn) {
if (!globalCache.has(key)) {
globalCache.set(key, fn());
}
return globalCache.get(key);
}

console.log(getOrCompute("pi", () => Math.PI.toFixed(10)));
console.log(getOrCompute("pi", () => Math.PI.toFixed(10))); // cache hit

// The pattern is fine — the cache is intentionally long-lived.
// The danger is unintentional long-lived references.

// Illustrating short-lived vs long-lived allocation patterns

// Short-lived — ideal. Objects born and die inside the function.
// V8's minor GC (Scavenge) handles these cheaply.
function processShortLived(data) {
// These allocations are all short-lived
const filtered = data.filter(x => x > 50);
const mapped = filtered.map(x => ({ value: x, grade: x >= 75 ? "A" : "B" }));
const result = mapped.reduce((acc, { grade }) => {
acc[grade] = (acc[grade] || 0) + 1;
return acc;
}, {});
return result;
}

const scores = Array.from({ length: 1000 }, (_, i) => (i * 37) % 100);
console.log(processShortLived(scores));

// Long-lived — objects that outlive the function they were created in.
// These get promoted to Old Space. GC cost is paid once, then amortised.
const globalCache = new Map(); // lives as long as the program

function getOrCompute(key, fn) {
if (!globalCache.has(key)) {
globalCache.set(key, fn());
}
return globalCache.get(key);
}

console.log(getOrCompute("pi", () => Math.PI.toFixed(10)));
console.log(getOrCompute("pi", () => Math.PI.toFixed(10))); // cache hit

// The pattern is fine — the cache is intentionally long-lived.
// The danger is unintentional long-lived references.

Short-lived allocations are cheap — the minor GC runs in microseconds and reclaims them. The old generation is collected less often but each collection takes longer. You want important persistent data in old space, and transient computations to stay short-lived.

Memory Leak Pattern 1 — Forgotten Event Listeners

The most common leak in browser applications. An event listener holds a reference to its callback, which closes over variables, which keeps entire object graphs alive:

JavaScript

Ctrl+Enter to run

// Simulating the event listener leak pattern
// (In a browser: element.addEventListener — here we simulate with a registry)

class EventBus {
#listeners = new Map();

on(event, fn) {
if (!this.#listeners.has(event)) this.#listeners.set(event, []);
this.#listeners.get(event).push(fn);
}

off(event, fn) {
const fns = this.#listeners.get(event) ?? [];
this.#listeners.set(event, fns.filter(f => f !== fn));
}

emit(event, data) {
(this.#listeners.get(event) ?? []).forEach(fn => fn(data));
}

listenerCount(event) {
return (this.#listeners.get(event) ?? []).length;
}
}

const bus = new EventBus();

// LEAK: adding listeners without removing them
function createLeakyComponent(id) {
const heavyState = new Array(1000).fill(id); // large closure variable

// This listener closes over heavyState — keeps it alive
bus.on("update", (data) => {
// heavyState is referenced here — it cannot be collected
return heavyState[0] + data;
});
}

// FIXED: clean up when done
function createCleanComponent(id) {
const heavyState = new Array(1000).fill(id);

const handler = (data) => heavyState[0] + data;
bus.on("update", handler);

// Return a cleanup function — call this when the component unmounts
return () => bus.off("update", handler);
}

// Leaky — 5 components added, none removed
for (let i = 0; i < 5; i++) createLeakyComponent(i);
console.log("After leak: listeners =", bus.listenerCount("update")); // 5, never cleaned

// Clean — 3 components added, all removed
const cleanups = [];
for (let i = 0; i < 3; i++) cleanups.push(createCleanComponent(i));
console.log("After clean add: listeners =", bus.listenerCount("update")); // 5 + 3 = 8
cleanups.forEach(cleanup => cleanup());
console.log("After cleanup: listeners =", bus.listenerCount("update")); // back to 5

// Simulating the event listener leak pattern
// (In a browser: element.addEventListener — here we simulate with a registry)

class EventBus {
#listeners = new Map();

on(event, fn) {
if (!this.#listeners.has(event)) this.#listeners.set(event, []);
this.#listeners.get(event).push(fn);
}

off(event, fn) {
const fns = this.#listeners.get(event) ?? [];
this.#listeners.set(event, fns.filter(f => f !== fn));
}

emit(event, data) {
(this.#listeners.get(event) ?? []).forEach(fn => fn(data));
}

listenerCount(event) {
return (this.#listeners.get(event) ?? []).length;
}
}

const bus = new EventBus();

// LEAK: adding listeners without removing them
function createLeakyComponent(id) {
const heavyState = new Array(1000).fill(id); // large closure variable

// This listener closes over heavyState — keeps it alive
bus.on("update", (data) => {
// heavyState is referenced here — it cannot be collected
return heavyState[0] + data;
});
}

// FIXED: clean up when done
function createCleanComponent(id) {
const heavyState = new Array(1000).fill(id);

const handler = (data) => heavyState[0] + data;
bus.on("update", handler);

// Return a cleanup function — call this when the component unmounts
return () => bus.off("update", handler);
}

// Leaky — 5 components added, none removed
for (let i = 0; i < 5; i++) createLeakyComponent(i);
console.log("After leak: listeners =", bus.listenerCount("update")); // 5, never cleaned

// Clean — 3 components added, all removed
const cleanups = [];
for (let i = 0; i < 3; i++) cleanups.push(createCleanComponent(i));
console.log("After clean add: listeners =", bus.listenerCount("update")); // 5 + 3 = 8
cleanups.forEach(cleanup => cleanup());
console.log("After cleanup: listeners =", bus.listenerCount("update")); // back to 5

The pattern: always pair addEventListener with removeEventListener, and always return a cleanup function from anything that registers a listener. React's useEffect return value exists precisely for this reason.

Memory Leak Pattern 2 — Unbounded Caches

A cache with no eviction policy is a memory leak with a delay:

JavaScript

Ctrl+Enter to run

// Unbounded cache — grows forever
const badCache = new Map();

function memoizeBad(fn) {
return function(key) {
if (!badCache.has(key)) {
badCache.set(key, fn(key));
}
return badCache.get(key);
};
}

// Simulate unbounded growth
const compute = memoizeBad(n => n * n);
for (let i = 0; i < 10000; i++) compute(i);
console.log("Bad cache size:", badCache.size); // 10000 — and growing

// LRU Cache — bounded, evicts least recently used
class LRUCache {
#cache;
#maxSize;

constructor(maxSize) {
this.#maxSize = maxSize;
this.#cache = new Map();
}

get(key) {
if (!this.#cache.has(key)) return undefined;
// Move to end (most recently used)
const value = this.#cache.get(key);
this.#cache.delete(key);
this.#cache.set(key, value);
return value;
}

set(key, value) {
if (this.#cache.has(key)) this.#cache.delete(key);
else if (this.#cache.size >= this.#maxSize) {
// Evict least recently used (first entry in Map)
this.#cache.delete(this.#cache.keys().next().value);
}
this.#cache.set(key, value);
}

get size() { return this.#cache.size; }
}

const lru = new LRUCache(100);
for (let i = 0; i < 10000; i++) {
if (!lru.get(i)) lru.set(i, i * i);
}
console.log("LRU cache size:", lru.size); // always <= 100

// LRU hit test
lru.set("a", 1); lru.set("b", 2); lru.set("c", 3);
lru.get("a"); // "a" is now most recently used
console.log("LRU get a:", lru.get("a")); // 1 — still there

// Unbounded cache — grows forever
const badCache = new Map();

function memoizeBad(fn) {
return function(key) {
if (!badCache.has(key)) {
badCache.set(key, fn(key));
}
return badCache.get(key);
};
}

// Simulate unbounded growth
const compute = memoizeBad(n => n * n);
for (let i = 0; i < 10000; i++) compute(i);
console.log("Bad cache size:", badCache.size); // 10000 — and growing

// LRU Cache — bounded, evicts least recently used
class LRUCache {
#cache;
#maxSize;

constructor(maxSize) {
this.#maxSize = maxSize;
this.#cache = new Map();
}

get(key) {
if (!this.#cache.has(key)) return undefined;
// Move to end (most recently used)
const value = this.#cache.get(key);
this.#cache.delete(key);
this.#cache.set(key, value);
return value;
}

set(key, value) {
if (this.#cache.has(key)) this.#cache.delete(key);
else if (this.#cache.size >= this.#maxSize) {
// Evict least recently used (first entry in Map)
this.#cache.delete(this.#cache.keys().next().value);
}
this.#cache.set(key, value);
}

get size() { return this.#cache.size; }
}

const lru = new LRUCache(100);
for (let i = 0; i < 10000; i++) {
if (!lru.get(i)) lru.set(i, i * i);
}
console.log("LRU cache size:", lru.size); // always <= 100

// LRU hit test
lru.set("a", 1); lru.set("b", 2); lru.set("c", 3);
lru.get("a"); // "a" is now most recently used
console.log("LRU get a:", lru.get("a")); // 1 — still there

An LRU cache bounded to 100 entries uses constant memory regardless of how many unique keys are requested. This is a production necessity for any cache keyed by user input or dynamic data.

Memory Leak Pattern 3 — Closures Holding Large Scopes

A closure captures its entire surrounding scope — not just the variables it uses. This can unexpectedly keep large objects alive:

JavaScript

Ctrl+Enter to run

// Subtle: closure captures the entire scope, not just used variables

function createHandler() {
const LARGE_DATA = new Array(100000).fill("x"); // 100k strings
const SMALL_VALUE = 42;

// This handler only uses SMALL_VALUE
// but LARGE_DATA is in the same scope — does it stay alive?
return function handler() {
return SMALL_VALUE; // only uses this
};

// In V8: modern engines are smart enough to only capture ACTUALLY used variables
// But not all engines are, and it depends on whether optimisation fired
}

const handler = createHandler();
console.log(handler()); // 42 — LARGE_DATA may or may not be collected

// Safer pattern: be explicit about what the closure needs
function createCleanHandler() {
const LARGE_DATA = new Array(100000).fill("x");
const SMALL_VALUE = 42;

// Process LARGE_DATA synchronously, extract only what's needed
const result = LARGE_DATA.length > 0 ? SMALL_VALUE : 0;

// Closure captures only 'result' — LARGE_DATA is definitely eligible for GC
return function handler() {
return result;
};
}

const cleanHandler = createCleanHandler();
console.log(cleanHandler()); // 42 — LARGE_DATA definitely collectable

console.log("\nRule: extract what you need from large data before closing over it");

// Subtle: closure captures the entire scope, not just used variables

function createHandler() {
const LARGE_DATA = new Array(100000).fill("x"); // 100k strings
const SMALL_VALUE = 42;

// This handler only uses SMALL_VALUE
// but LARGE_DATA is in the same scope — does it stay alive?
return function handler() {
return SMALL_VALUE; // only uses this
};

// In V8: modern engines are smart enough to only capture ACTUALLY used variables
// But not all engines are, and it depends on whether optimisation fired
}

const handler = createHandler();
console.log(handler()); // 42 — LARGE_DATA may or may not be collected

// Safer pattern: be explicit about what the closure needs
function createCleanHandler() {
const LARGE_DATA = new Array(100000).fill("x");
const SMALL_VALUE = 42;

// Process LARGE_DATA synchronously, extract only what's needed
const result = LARGE_DATA.length > 0 ? SMALL_VALUE : 0;

// Closure captures only 'result' — LARGE_DATA is definitely eligible for GC
return function handler() {
return result;
};
}

const cleanHandler = createCleanHandler();
console.log(cleanHandler()); // 42 — LARGE_DATA definitely collectable

console.log("\nRule: extract what you need from large data before closing over it");

Memory Leak Pattern 4 — Detached DOM Nodes

This one is browser-specific but worth understanding. If you keep a JavaScript reference to a DOM node after it has been removed from the document, the entire subtree stays in memory even though the user cannot see it:

JavaScript

Ctrl+Enter to run

// Simulating the detached node pattern (no DOM in sandbox — pure JS analogy)

class TreeNode {
constructor(id, data) {
this.id = id;
this.data = new Array(1000).fill(id); // simulate heavy node
this.children = [];
}

add(child) { this.children.push(child); return this; }
}

// A "document" that holds a tree
class Document {
#root;
constructor() { this.#root = new TreeNode("root", []); }
get root() { return this.#root; }
removeChild(id) {
this.#root.children = this.#root.children.filter(c => c.id !== id);
}
}

const doc = new Document();
const section = new TreeNode("section");
doc.root.add(section);

// LEAK: we hold a reference to section outside the document
const detachedRef = section; // ← this is the problem

doc.removeChild("section"); // removed from tree
// But detachedRef still holds section — and section.data (1000 items)
// The whole subtree cannot be collected

console.log("Removed from tree but still in memory:", detachedRef.id);
console.log("Children held alive:", detachedRef.children.length);

// FIX: null out the reference when done
// detachedRef = null; — can't reassign const, but set to null in real code
console.log("\nFix: set detachedRef = null after removing from tree");

// Simulating the detached node pattern (no DOM in sandbox — pure JS analogy)

class TreeNode {
constructor(id, data) {
this.id = id;
this.data = new Array(1000).fill(id); // simulate heavy node
this.children = [];
}

add(child) { this.children.push(child); return this; }
}

// A "document" that holds a tree
class Document {
#root;
constructor() { this.#root = new TreeNode("root", []); }
get root() { return this.#root; }
removeChild(id) {
this.#root.children = this.#root.children.filter(c => c.id !== id);
}
}

const doc = new Document();
const section = new TreeNode("section");
doc.root.add(section);

// LEAK: we hold a reference to section outside the document
const detachedRef = section; // ← this is the problem

doc.removeChild("section"); // removed from tree
// But detachedRef still holds section — and section.data (1000 items)
// The whole subtree cannot be collected

console.log("Removed from tree but still in memory:", detachedRef.id);
console.log("Children held alive:", detachedRef.children.length);

// FIX: null out the reference when done
// detachedRef = null; — can't reassign const, but set to null in real code
console.log("\nFix: set detachedRef = null after removing from tree");

Measuring Memory — What You Can Observe

In the sandbox performance.memory is not available, but in a real browser or Node.js process you have tools:

JavaScript

Ctrl+Enter to run

// performance.memory is Chrome-only and not in all sandboxes
// Here we demonstrate measurement patterns you can use in real environments

// Pattern 1: track allocation counts manually
class AllocationTracker {
#counts = new Map();

track(type) {
this.#counts.set(type, (this.#counts.get(type) || 0) + 1);
}

release(type) {
const n = this.#counts.get(type) || 0;
if (n > 0) this.#counts.set(type, n - 1);
}

report() {
console.log("Live allocations:");
for (const [type, count] of this.#counts) {
console.log(` ${type}: ${count}`);
}
}
}

const tracker = new AllocationTracker();

class TrackedStudent {
constructor(name) {
this.name = name;
tracker.track("Student");
}
destroy() { tracker.release("Student"); }
}

const s1 = new TrackedStudent("Rahul");
const s2 = new TrackedStudent("Priya");
const s3 = new TrackedStudent("Arjun");
tracker.report(); // 3 live

s1.destroy();
s2.destroy();
tracker.report(); // 1 live

// Pattern 2: in Node.js use process.memoryUsage()
// const before = process.memoryUsage().heapUsed;
// ... do work ...
// const after = process.memoryUsage().heapUsed;
// console.log('Δ heap:', ((after - before) / 1024).toFixed(1), 'KB');

console.log("\nIn Chrome DevTools: Memory tab → Take Heap Snapshot");
console.log("In Node.js: process.memoryUsage().heapUsed");
console.log("In Node.js: --expose-gc flag → global.gc() to force collection");

// performance.memory is Chrome-only and not in all sandboxes
// Here we demonstrate measurement patterns you can use in real environments

// Pattern 1: track allocation counts manually
class AllocationTracker {
#counts = new Map();

track(type) {
this.#counts.set(type, (this.#counts.get(type) || 0) + 1);
}

release(type) {
const n = this.#counts.get(type) || 0;
if (n > 0) this.#counts.set(type, n - 1);
}

report() {
console.log("Live allocations:");
for (const [type, count] of this.#counts) {
console.log(` ${type}: ${count}`);
}
}
}

const tracker = new AllocationTracker();

class TrackedStudent {
constructor(name) {
this.name = name;
tracker.track("Student");
}
destroy() { tracker.release("Student"); }
}

const s1 = new TrackedStudent("Rahul");
const s2 = new TrackedStudent("Priya");
const s3 = new TrackedStudent("Arjun");
tracker.report(); // 3 live

s1.destroy();
s2.destroy();
tracker.report(); // 1 live

// Pattern 2: in Node.js use process.memoryUsage()
// const before = process.memoryUsage().heapUsed;
// ... do work ...
// const after = process.memoryUsage().heapUsed;
// console.log('Δ heap:', ((after - before) / 1024).toFixed(1), 'KB');

console.log("\nIn Chrome DevTools: Memory tab → Take Heap Snapshot");
console.log("In Node.js: process.memoryUsage().heapUsed");
console.log("In Node.js: --expose-gc flag → global.gc() to force collection");

WeakMap and WeakRef as Memory-Safe Patterns

You saw these in the previous lesson. The memory angle: WeakMap entries do not prevent GC, making them the right tool for any cache or metadata store keyed by objects whose lifetime you do not control:

JavaScript

Ctrl+Enter to run

// WeakMap cache — entries evicted automatically when key is collected
const computedResults = new WeakMap();

function expensiveCompute(obj) {
if (computedResults.has(obj)) {
return computedResults.get(obj); // cached
}
// Simulate expensive computation
const result = Object.values(obj).reduce((a, b) => {
return typeof b === "number" ? a + b : a;
}, 0);
computedResults.set(obj, result);
return result;
}

let data1 = { physics: 82, chemistry: 91, maths: 78 };
let data2 = { physics: 55, chemistry: 63, maths: 70 };

console.log(expensiveCompute(data1)); // computed
console.log(expensiveCompute(data1)); // cached
console.log(expensiveCompute(data2)); // computed

// When data1 goes out of scope, its WeakMap entry is collected too
// No manual cache invalidation needed — ever
data1 = null;
// computedResults entry for old data1 is now eligible for GC

console.log(expensiveCompute(data2)); // still cached

console.log("\nWeakMap: the only cache that cannot leak by design");

What You Have Learned

Memory management in JavaScript is automatic but not effortless. The garbage collector handles reachability correctly — your job is to not accidentally keep things reachable longer than necessary.

The key ideas:

The GC collects objects that are unreachable from roots — circular references between unreachable objects are handled correctly
V8's heap is generational: most objects die young in New Space (cheap minor GC); survivors are promoted to Old Space (less frequent, slower major GC)
The four common leak patterns: forgotten event listeners, unbounded caches, closures holding large scopes, and detached DOM node references
An LRU cache with a fixed size bound is the correct pattern for any cache keyed by dynamic data
WeakMap is the only cache that cannot leak — entries disappear when their key object is collected
Measure with process.memoryUsage() in Node.js, Chrome DevTools Memory tab in the browser, or a manual allocation tracker during development
Prefer extracting what you need from large data before closing over it — do not rely on the engine being smart about unused variables in scope

In the next lesson: Functional Programming Patterns — pure functions, immutability, function composition, currying, and monads. The programming paradigm that eliminates an entire category of bugs by making state changes impossible rather than just careful.

Memory Management & Garbage Collection

Memory Is Not Infinite

The Generational Heap

Memory Leak Pattern 1 — Forgotten Event Listeners

Memory Leak Pattern 2 — Unbounded Caches

Memory Leak Pattern 3 — Closures Holding Large Scopes

Memory Leak Pattern 4 — Detached DOM Nodes

Measuring Memory — What You Can Observe

WeakMap and WeakRef as Memory-Safe Patterns

What You Have Learned