Reclaiming unused objects

Programs allocate memory for lists, objects, and other dynamic values. Manual deallocation can retain abandoned objects or free storage while it is still needed. Garbage collection transfers part of that responsibility to the runtime, which must use an explicit rule for deciding which objects can safely be reclaimed.

References: [1] [2]

Tracing from roots

A tracing collector starts from roots known to be in use and follows references through the object graph. Objects unreachable from those roots can be reclaimed even when they refer to one another. Marking, sweeping, and moving storage are implementation choices built around this distinction between reachable and unreachable data.

References: [1]

Reference counts and cycles

Reference counting tracks references to an object and can release it when its count reaches zero. A disconnected cycle can nevertheless keep nonzero counts. CPython therefore supplements its reference-counting system with a collector for cycles. Its documented gc interface illustrates how multiple reclamation techniques can coexist in one implementation.

References: [2]

Paying for collection

Collection consumes CPU time and affects memory demand and latency. More frequent collection may reduce memory use while increasing work; longer intervals make a different tradeoff. Objects retained through reachable references remain live to a tracing collector, even when the application no longer has a useful purpose for them.

References: [1] [2]