Comparing mostly-copying and mark-sweep conservative collection

Abstract

Many high-level language compilers generate C code and then invoke a C compiler for code generation. To date, most of these compilers link the resulting code against a conservative mark-sweep garbage collector in order to reclaim unused memory. We i n troduce a new collector, MCC, based on an extension of mostly-copying collection. We analyze the various design decisions made in MCC and provide a performance comparison to the most widely used conservative mark-sweep collector the Boehm-Demers-Weiser collector. Our results show that a good mostlycopying collector can outperform a mature highly-optimized mark-sweep collector when physical memory is large relative to the live data. A surprising result of our analysis is that cache behavior can have a greater impact on overall performance than either collector time or allocation time.

Application-specific garbage collection

“…Other studies have identified similar opportunities Zorn, 1990;Smith and Morrisett, 1998). IBM's Persistent Reusable JVM attempts to split the heap into multiple parts grouped by their expected lifetimes, employs heap-specific GC models and heap-expansion to avoid GCs.…”

“…The goal of most of this prior work has been to provide general-purpose mechanisms that enable high performance execution across all applications. However, many researchers, including ourselves, find that the performance of a memory management system (the allocator and the garbage collector) is dependent upon application behavior and available resources (Soman et al, 2004;Attanasio et al, 2001;Fitzgerald and Tarditi, 2000;Zorn, 1990;Smith and Morrisett, 1998). That is, no single collection system enables the best performance for all applications and all heap sizes and the difference in performance can be significant.…”

Using page residency to balance tradeoffs in tracing garbage collection

“…Simultaneously supporting ambiguous roots and heap compaction is only one way that mostly copying collection can balance the tradeoffs of copying and noncopying collection: there are other opportunities to use inplace promotion. In particular, it is well-recognized [26] that there is little or no benefit in copying objects that consume all of the space associated with a page. These large objects are expensive to copy, both in terms of the time required to do so and the additional space required for the duplicate.…”

“…Previous implementations of mostly copying collection [3,26] promoted pages only in the presence of ambiguous roots or large objects. We extend this work and use page residency, the density of reachable objects on a page, to determine when to promote or evacuate the objects on a given page.…”

“…Evacuated objects are assigned forwarding pointers to ensure that each object is copied at most once. In these aspects of our implementation, we follow the work Smith and Morrisett [26].…”