Garbage Collection as Automatic Lifetime Management¶

Rather than requiring explicit deallocation, the runtime can automatically reclaim memory that is no longer reachable - trading programmer burden for runtime overhead and non-deterministic cleanup timing.

Tension Addressed¶

Convenience vs. Control

Recognizable As¶

No explicit "free" or "delete"; GC pauses; memory growing until collection; finalizers/destructors with uncertain timing; "managed" vs. "native" code distinction

Canonical Sources¶

McCarthy, "Recursive Functions of Symbolic Expressions" (1960, first GC); Wilson, "Uniprocessor Garbage Collection Techniques" (1992); Jones & Lins, Garbage Collection: Algorithms for Automatic Dynamic Memory Management (1996)

Transfers To¶

Resource cleanup in any domain (file handles, connections), distributed garbage collection, cache eviction strategies

GC represents a fundamental trade-off: eliminate memory bugs by giving up deterministic cleanup and accepting runtime overhead. The two primary strategies (reference counting vs. tracing) have complementary strengths: reference counting has deterministic cleanup but can't handle cycles; tracing handles cycles but has unpredictable pauses.

Sub-concepts: - Reference counting: Each object tracks how many references point to it; freed when count reaches zero - Tracing collection: Periodically scan from "root" references to find unreachable objects