What Is Garbage Collection? Memory Management Without the Manual Work

One missing free() contributed to the Heartbleed vulnerability in OpenSSL. Firefox ships use-after-free patches to this day. Manual memory management is either correct or exploitable. Rarely both.

Garbage collection is the runtime mechanism that automatically reclaims memory your program can no longer reach, so you never have to free it yourself. Python, Java, Go, JavaScript, Ruby, C# all make that tradeoff. You allocate freely. The runtime figures out when to reclaim.

Why C Makes You Pay

In C, you own every byte you allocate. Call malloc, get memory. When you're done, call free. Forget and you have a leak. Free too early and the next access crashes. Free the same pointer twice and you have a double-free, which is exploitable. Pick your poison. C lets you pick all three on the same Tuesday afternoon.

int *build_array(int n) {
    int *arr = malloc(n * sizeof(int));
    // populate arr...
    return arr;
    // caller MUST call free(arr) later or memory is leaked
}

The caller must remember. At some point in some codebase, someone's caller forgot.

GC trades control for safety. Getting manual memory management right at scale is genuinely hard. Heartbleed was written by people who were trying. Most modern languages make that tradeoff automatically, because the alternative is letting security researchers have all the fun.

The C++ developer's entire career, summarized.

What "Garbage" Actually Means

A garbage collector's job is to find memory your program can no longer reach and reclaim it.

Reachability is the key concept. An object is reachable if any live reference points to it, directly or through a chain. The GC starts from the roots (local variables on the stack, global variables, CPU registers) and follows every pointer. Anything reachable is alive. Everything else is garbage.

def compute():
    a = [1, 2, 3]   # reachable: 'a' on the stack
    b = a           # reachable via both 'a' and 'b'
    a = None        # 'a' points elsewhere now
    b = None        # no references remain, [1, 2, 3] is garbage

The moment that list has no references, it becomes eligible for collection. You never call free. The runtime does the accounting. You just write code and occasionally wonder why your process is using 2GB.

Reference Counting Dies on Cycles. Mark-and-Sweep Pauses.

Reference Counting

Every object carries a counter tracking how many references point to it. When a reference is created, increment. When destroyed, decrement. When the count reaches zero, free immediately.

Python's primary GC is reference counting. Each Python object has an ob_refcnt field that CPython updates automatically.

import sys

x = [1, 2, 3]
print(sys.getrefcount(x))  # 2, x plus getrefcount's own argument
y = x
print(sys.getrefcount(x))  # 3
del y
print(sys.getrefcount(x))  # back to 2

The appeal is determinism. Memory is freed the instant it's unreachable. No pauses, no surprises.

The problem is cycles. If object A holds a reference to B, and B holds a reference to A, and nothing outside points to either of them, both counts sit at 1 forever. Reference counting never frees them. Both objects sit in memory, pointing at each other, technically alive, completely useless. Like two people each waiting for the other to hang up first.

class Node:
    def __init__(self):
        self.other = None

a = Node()
b = Node()
a.other = b
b.other = a
a = None
b = None
# both nodes are garbage, but their refcounts are 1, not 0

Python ships a separate cycle detector in the gc module to handle exactly this. It runs periodically and uses a generational traversal to find cyclic garbage the reference counter missed. You can trigger it manually with gc.collect().

Mark-and-Sweep

Mark every reachable object, then sweep through the heap and free everything unmarked.

Phase 1 (mark): start from the roots, do a full graph traversal, mark each visited object.
Phase 2 (sweep): walk the entire heap. Free anything unmarked.

Mark-and-sweep handles cycles natively. A cycle with no external references gets skipped in the mark phase, so both objects get swept. No special case needed.

The classic cost is the stop-the-world pause. The GC freezes all your threads during traversal. Moving memory while threads are reading it would corrupt everything. Modern collectors reduce this significantly. Go's concurrent GC keeps stop-the-world pauses under 100 microseconds by doing most marking work concurrently with your program. Java offers G1, ZGC, and Shenandoah for low-latency workloads. Some pause almost always remains, but the worst cases are now the exception.

Most Objects Die Young. The GC Knows This.

Most production GCs layer a generational strategy on top. The empirical observation: most objects die young. The list you build in a function, the intermediate string, the temporary node. These last microseconds, not minutes. Objects, like startups, are mostly short-lived.

Divide the heap into generations. New objects go into the young generation. The GC collects the young generation frequently because that's where most garbage is. Objects that survive several collections get promoted to the old generation, which is collected rarely.

Java calls these Eden, Survivor, and Old Gen. Python's cycle detector uses three numbered generations (0, 1, 2). Go uses a similar concept through its scavenger. The details differ. The insight is the same: spend your GC budget where most garbage lives. In Java, a minor GC (young generation only) might run every few hundred milliseconds and finish in under a millisecond. A major GC is much rarer, but noticeably slower.

GC Is Not Free

Three costs that matter.

Throughput. Every CPU cycle the GC uses is a cycle your program isn't. A well-tuned JVM app might spend 5-10% of runtime in GC. Under heavy allocation pressure, that climbs.

Pause latency. Stop-the-world pauses are invisible until they aren't. For a game, a trading platform, or a real-time stream, even 50ms is visible to users. This is why Go targets sub-millisecond pauses and why Java has multiple GC implementations tuned for different latency vs. throughput tradeoffs.

Memory overhead. GC languages carry metadata on every object. In Java, each object has a 12-byte header for GC bookkeeping. In CPython, each object carries a reference count plus type pointer. A bare Python integer uses around 28 bytes. You're never just paying for the data itself.

The most efficient garbage collection strategy: remove Java entirely.

Why This Matters in Coding Interviews

Interviewers almost never ask "what is garbage collection" directly. The mechanics surface constantly anyway.

Intermediate objects still cost space. When you create objects and discard them, that's still space your program used, even if GC reclaims it before you return. A function that builds n temporary strings has O(n) space usage. String concatenation in a loop is the textbook case: each += in Python or Java creates a new string object. The old one becomes garbage immediately, but you've spent O(n²) total allocation by the time you finish. "".join(parts) allocates exactly once.

Recursion allocates on the heap too. The call stack holds frames, but objects you create inside each call go on the GC-managed heap. A recursive function that builds a copy of the input at each level has O(n) heap allocations live simultaneously, not one. The recursion space complexity post covers this in detail.

References are not copies. Two variables pointing at the same object means mutations through one are visible through the other. This is the most common backtracking bug in interview code. When you append a list to your results, you're storing a reference. Mutate the list after and you've corrupted every result you stored.

results = []

def backtrack(path):
    if is_complete(path):
        results.append(path[:])  # copy, not reference, this is correct
        return
    for choice in choices:
        path.append(choice)
        backtrack(path)
        path.pop()

Skipping the [:] is the bug. GC has nothing to do with it. Understanding that path is a reference is the fix.

You don't need to free nodes. If you're splicing a linked list or restructuring a tree in a GC language, just reassign pointers. Nodes with no remaining references become garbage and get collected. No cleanup, no dangling pointers.

The Honest Tradeoff

GC languages give you memory safety and faster development at the cost of runtime overhead and nondeterministic pauses. C and C++ give you precise control and predictable performance at the cost of every memory bug being your problem. Rust tries to get both: no GC, no manual free, and memory safety enforced at compile time through a borrow checker. Getting the borrow checker to accept your code is its own special experience, but at least it's a compile-time experience and not a 3am production incident.

Each choice is correct for different constraints. For more on stack vs. heap memory, that post covers the memory model underneath everything here.

What to Remember

• GC reclaims memory that's no longer reachable. No live references means collectable.
• Reference counting frees immediately but can't handle cycles. Mark-and-sweep handles cycles but pauses execution.
• In interviews: GC doesn't eliminate space usage. Intermediate allocations still count. Two variables pointing at the same object are not two copies.

If you want to practice explaining memory behavior clearly under pressure, SpaceComplexity runs voice-based DSA mock interviews with rubric-based feedback. Saying "this uses O(1) extra space" and having an interviewer ask you to justify it is exactly the kind of practice that locks in the difference between GC reclaiming memory and memory never being used.

Further Reading

• Wikipedia: Garbage collection (computer science)
• Python documentation: gc module
• A Guide to the Go Garbage Collector
• Oracle: HotSpot Virtual Machine Garbage Collection Tuning Guide
• GeeksforGeeks: Garbage Collection in Java