Pathological Cases for a Class of Reachability-Based Garbage Collectors

Although existing garbage collectors (GCs) perform extremely well on typical programs, there still exist pathological programs for which modern GCs significantly degrade performance. This observation begs the question: might there exist a ‘holy grail’ GC algorithm, as yet undiscovered, guaranteeing both constant-length pause times and that memory is collected promptly upon becoming unreachable? For decades, researchers have understood that such a GC is not always possible, i.e., some pathological behavior is unavoidable when the program can make heap cycles and operates near the memory limit, regardless of the GC algorithm used. However, this understanding has until now been only informal, lacking a rigorous formal proof. This paper complements that informal understanding with a rigorous proof, showing with mathematical certainty that every GC that can implement a realistic mutator-observer interface has some pathological program that forces it to either introduce a long GC pause into program execution or reject an allocation even though there is available space. Hence, language designers must either accept these pathological scenarios and design heuristic approaches that minimize their impact (e.g., generational collection), or restrict programs and environments to a strict subset of the behaviors allowed by our mutator-observer-style interface (e.g., by enforcing a type system that disallows cycles or overprovisioning memory).

💡 Research Summary

The paper addresses a fundamental question in garbage collection (GC): can a GC algorithm guarantee both constant‑length pause times and immediate reclamation of memory as soon as it becomes unreachable? While practitioners have long suspected that such a “holy‑grail” collector cannot exist, prior arguments were informal. The authors provide a rigorous, mathematically‑based impossibility proof for a broad class of reachability‑based collectors that implement a realistic mutator‑observer interface (which they formalize as the Garbage Collection Data Structure, GCDS).

Model and Performance Metrics
The GCDS interface models the interaction between a mutator (the running program) and an observer (the GC). The mutator streams pointer updates (insertions, deletions, re‑assignments) to the observer. The observer must add a region to the free list once it becomes unreachable. Two key performance measures are defined: (1) pause time – the maximum extra time a single mutator instruction incurs because of GC work, and (2) collection delay – the number of mutator operations that must elapse before an unreachable region is actually reclaimed.

Reduction to Dynamic Graph Reachability
The authors observe that the heap can be represented as a dynamic directed graph: vertices are memory regions, edges are pointers. Determining whether a region has become unreachable after a pointer update is exactly the dynamic graph reachability problem. In the graph‑algorithms literature, lower bounds for this problem are well‑known: after an edge deletion, answering reachability queries requires at least Ω(log n) (and in some models Ω(n)) time in the worst case. By reducing GC’s collection‑delay requirement to this problem, they prove that if a collector tries to keep collection delay O(1), it must spend Ω(n) time per mutator operation, which translates into super‑constant pause times. Conversely, if pause time is kept constant, the collector must tolerate at least Ω(log n) collection delay. This trade‑off is formalized in Theorem 4.5 and its corollary.

Concrete Pathological Example (GC Thrashing)
To illustrate the practical impact, the paper presents a Lua program that first allocates a large set of permanent objects, pushing memory usage near the limit, and then repeatedly allocates temporary buffers while freeing the previous ones. Because the GC cannot reclaim the just‑freed buffer quickly enough, each iteration forces a full‑heap collection, leading to “GC thrashing.” Empirical measurements show a 70× slowdown compared with a manually managed version, confirming the theoretical lower bound in a realistic scenario.

Reference Counting and Cycles
Section 5 extends the impossibility argument to reference‑counting collectors. Handling cycles requires a cycle‑detection phase that is again equivalent to dynamic reachability, implying that any extension of reference counting capable of reclaiming cyclic garbage must either increase pause time dramatically or introduce substantial collection delay, even on programs whose heaps are otherwise acyclic.

Scope and Limitations
The results apply only to collectors that can be expressed via the GCDS interface (essentially non‑moving, reachability‑based collectors). Moving collectors, approximated liveness analyses, or systems that enforce strict type‑level restrictions (e.g., forbidding cycles) are outside the formal scope. The lower bounds guarantee the existence of at least one pathological input; they do not claim that typical workloads will suffer.

Positive Result for Acyclic Heaps
Despite the negative findings, the authors describe a novel collector (Section 7) that, on acyclic heaps, achieves O(1) collection delay and O(log n) pause time by maintaining a dynamic tree structure and performing incremental updates. The algorithm incurs prohibitive overhead when cycles appear and, in empirical tests, does not outperform conventional generational collectors on ordinary programs, so it is not recommended for general use. Nonetheless, it demonstrates that the lower bound can be tightened under additional heap‑shape assumptions.

Implications
The paper provides the first formal proof that any GC adhering to the mutator‑observer model must suffer either long pauses or long reclamation delays in the worst case. This validates the long‑standing intuition among GC researchers and justifies the continued reliance on heuristics such as generational collection, over‑provisioning of memory, or type‑system restrictions that eliminate cycles. It also opens a bridge between programming‑language GC theory and dynamic graph algorithms, suggesting that advances (or impossibility results) in one field directly inform the other.

Future Directions
The authors suggest strengthening the dynamic‑reachability lower bound (potentially to linear) to sharpen the GC impossibility result, extending the analysis to moving collectors and other GC interfaces, and exploring practical implementations of the O(1)‑delay, logarithmic‑pause collector for specialized domains where acyclic heaps can be guaranteed.

In summary, the paper rigorously establishes that for a wide class of realistic garbage collectors, pathological cases are unavoidable: one cannot simultaneously achieve constant pause times and prompt reclamation when programs can create heap cycles and operate near memory limits. The work clarifies the theoretical limits of GC, informs language and runtime designers, and points to promising interdisciplinary research avenues.