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-alone 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.

Dynamic selection of application-specific garbage collectors

“…We refer to any point at which the bestperforming GC system changes as a switch point. These results support the findings of others [4,16,42], that no single collection system enables the best performance across benchmarks; moreover no single system performs best across heap sizes for a single benchmark/input pair.…”

“…However, many researchers have shown that there is no single combination of a collector and an allocator that enables the best performance for all applications, on all hardware, and given all resource constraints [4,16,42]. Figure 1 confirms these findings.…”

“…For example, Fitzgerald and Tarditi [16] performed a detailed study comparing the relative performance of applications using several variants of generational and non-generational semispace 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, other prior research [4,16,42,36] has shown that the efficacy of a memory management system (the allocator and the garbage collector) is dependent upon application behavior and available resources. That is, no single collection system enables the best performance for all applications and all heap sizes.…”

Garbage collection auto-tuning for Java mapreduce on multi-cores

“…It is a well-established fact that the relative performance of different GC algorithms is dependent on the characteristics of the application being executed [17,28,35] particularly at smaller heap sizes.…”