The case for profile-directed selection of garbage collectors

Abstract

Many garbage-collected systems use a single garbage collection algorithm across all applications. It has long been known that this can produce poor performance on applications for which that collector is not well suited. In some systems, such as those that execute stand-Mone compiled executables, an appropriate collector for each application can be selected from a pool of available collectors and tuned by using profile information. In a study of 20 benchmarks and several collectors, compiled with the Marmot optimizing Java-to-native compiler, for every collector there was at least one benchmark that would have been at least 15% faster with a more appropriate collector. The collectors are a copying collector, a generational copying collector, which is combined with each of 4 different write barriers, and the null collector, which allocates but never collects. A detailed analysis of storage management costs shows how they vary by application and collector.

Application-specific garbage collection

“…The collectors will be described in detail shortly. These results support the findings of others Fitzgerald and Tarditi, 2000;Zorn, 1990), that no single collection system enables the best performance across benchmarks. Further, no single system performs best across heap sizes for a single benchmark/input pair.…”

“…1. This set of experiments confirms similar findings of others Fitzgerald and Tarditi, 2000;Zorn, 1990) that indicate that no single GC system enables the best performance for all applications, on all hardware, and given all resource constraints.…”

“…For example, Fitzgerald and Tarditi (2000) performed a detailed study comparing the relative performance of applications using several variants of generational and non-generational copying collectors (the variations had to do with the write barrier implementations). They showed that over a collection of 20 benchmarks, each collector variant sometimes provided the best performance.…”

“…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.…”

Oil and water? High performance garbage collection in Java with MMTk

“…Although researchers have studied garbage collection for a long time [2,19,20,25,27,34], this reliance on it and growing locality effects have made garbage collection research a high priority in academia [13,17,26,30,32] and industry [8,9,10]. Many collector implementations are monolithic and do not share reused components [1,21]. Performance comparisons across a range of approaches is thus problematic and rare [4,7,21].…”