Garbage collection is an essential part of modern managed languages, such as Java, that are used in billions of devices and in a large variety of settings. Multiple garbage collectors (GCs) have been developed over the last several decades, in an attempt to optimize across a complex design space that includes memory footprint for GC metadata, thread concurrency with the mutator (i.e., the application), performance, and the footprint of stale data. While aggregate runtime metrics have been used to guide modern GC design, it has been difficult to use such metrics to capture the fine-grained performance and energy impact that GC execution has on the memory system. We develop a novel low-overhead methodology for measuring the cost of GCs, by combining isolated thread monitoring using a combination of real hardware and calibrated cycle-accurate simulation, which allows us to perform fine-grained analysis of modern GC overheads. We use our methodology to make several observations about the overheads of six modern Java GCs on the memory system, including: (1) the GCs introduce a substantially higher overhead on L3 cache accesses compared to L1 cache accesses at all levels of GC pressure analyzed; (2) GC loads require more time on average to be serviced, a cost that increases with reduction in GC pressure; (3) GC accesses generally do not improve application cache hits, as the potential benefits of prefetching application data are counteracted by GC–application interference; and (4) modern highly-concurrent GCs account for most of the useless prefetching due to L2 hardware prefetching triggered by workload execution. Our work highlights the assumed memory system overheads of GC not captured by existing metrics, and aims to encourage future work in optimizing GCs for the memory system.
No takes yet. Share an insight, caveat, or question.
Agarwal et al. (2026) studied this question.
Synapse has enriched 4 closely related papers on similar clinical questions. Consider them for comparative context: