Memory Management & Garbage Collection (GC) in JavaScript

Unlike low-level languages (like C or C++), where developers must manually allocate and free memory using malloc() and free(), JavaScript manages memory automatically. The JavaScript engine allocates memory when variables and objects are created and cleans it up using a Garbage Collector (GC) when they are no longer needed.

However, automatic memory management does not mean you can ignore memory entirely. Understanding how the V8 engine (and others) handles memory is critical to preventing memory leaks in large-scale applications.

1. The Memory Lifecycle

Regardless of the language, the memory lifecycle is always the same:

1. Allocate memory you need (e.g., declaring a variable).
2. Use the allocated memory (reading/writing).
3. Release the allocated memory when it is no longer needed (handled by GC in JS).

2. Stack vs. Heap

JavaScript engine memory is divided into two main areas:

• The Stack: Static memory allocation. Used for primitive values (Number, String, Boolean, null, undefined, Symbol) and function execution contexts. The stack is fast, structured, and operates on a Last-In-First-Out (LIFO) basis. Variables have a fixed size.
• The Heap: Dynamic memory allocation. Used for storing objects, arrays, and functions. The heap is an unstructured region of memory where large blocks of data are stored. When you assign an object to a variable, the stack holds a reference (pointer) to the location of the object in the heap.

3. Garbage Collection Algorithms

The main concept of JavaScript garbage collection relies on the concept of reachability. If an object is reachable from the root (the global object, e.g., window or global), it is kept in memory. If it is unreachable, it is garbage collected.

Mark-and-Sweep Algorithm

This is the most common algorithm used by modern engines.

1. Mark: The GC starts at the roots (global variables, current execution stack). It traverses the tree of references and marks every object it can reach as "active".
2. Sweep: The GC scans the heap memory. Any memory addresses that are not marked as active are considered unreachable and are freed.

Generational Garbage Collection (V8 Optimization)

V8 splits the heap into two generations to optimize performance:

• Young Generation: Newly allocated objects go here. Most objects "die young" (e.g., variables in a function). The GC runs frequently here (Minor GC) and is very fast.
• Old Generation: Objects that survive multiple Minor GCs in the young generation are moved here. These are long-lived objects. The GC runs less frequently here (Major GC) using the full mark-and-sweep, which is more computationally expensive.

4. Common Memory Leaks in JavaScript

Even with automatic GC, memory leaks happen when developers accidentally keep references to objects they no longer need, preventing the GC from sweeping them.

1. Accidental Global Variables

Variables declared without let, const, or var in non-strict mode become attached to the global window object. Since the global object is never garbage collected, these variables leak.

function accidentalLeak() {
  leakedData = new Array(10000); // Missing 'let'/'const'
}

2. Forgotten Timers or Callbacks

If you start a setInterval that references objects in a closure, and you forget to call clearInterval, those objects will never be garbage collected.

const hugeData = loadData();
setInterval(() => {
  console.log(hugeData); // hugeData is trapped in memory forever
}, 1000);

3. Out-of-DOM References

If a DOM element is removed from the document, but you still keep a reference to it in a JavaScript variable or object, it remains in memory (a "Detached DOM element").

let detachedNodes = [];
function removeElement() {
  const node = document.getElementById('button');
  document.body.removeChild(node);
  detachedNodes.push(node); // Prevents GC!
}

4. Closures

Closures keep references to variables in their outer lexical environment. If a closure is attached to a long-lived object, it can inadvertently keep large scopes alive.

5. Identifying Leaks: Chrome DevTools

You can profile memory using the Chrome DevTools Memory tab:

• Heap Snapshot: Takes a snapshot of the current memory distribution. You can compare two snapshots (before and after an action) to see what objects were not cleaned up.
• Allocation Instrumentation on Timeline: Records memory allocations in real-time, helping you spot repeating memory spikes (sawtooth patterns).

6. Advanced Tools: WeakMap and WeakRef

To prevent holding onto objects unnecessarily, ES6 introduced WeakMap and WeakSet, where keys are held weakly. If there are no other references to a key object, the GC will collect it. ES2021 introduced WeakRef and FinalizationRegistry for advanced, manual observation of garbage collection, though they should be used sparingly.