Distilling the Real Cost of Production Garbage Collectors

Cai, Zixian; Blackburn, Stephen M.; Bond, Michael D.; Maas, Martin

doi:10.1109/ispass55109.2022.00005

Cited by 9 publications

(7 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…It serves precisely as a tool for comparing and diagnosing GC problems. However, in some cases, applications may end up being slower without memory management than with any GC [5]. This issue prevents performance comparisons with and without GC in order to measure overheads.…”

Section: Challengesmentioning

confidence: 99%

“…In other words, the application threads execute instructions that do not belong to the application's code in order to help the GC perform the collection. However, this additional work is so deeply interleaved within the execution, that identifying the overhead that results from it is particularly difficult [5].…”

Section: Challengesmentioning

confidence: 99%

“…Therefore, most modern GCs [10,32] have increasingly shorter pauses, while performing most of the work concurrently with the application threads (e.g., ZGC [32]). However, concurrency comes at a price as well [5], as the application needs to share resources with the GC (e.g., cache capacity, bandwidth, CPU time) and even sometimes help with the collection itself. To the best of our knowledge, there is no work on concurrent GCs that quantifies these overhead components individually.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Concurrent GCs and Modern Java Workloads: A Cache Perspective

Carpen-Amarie¹,

Vavouliotis²,

Tovletoglou³

et al. 2023

Proceedings of the 2023 ACM SIGPLAN International Symposium on Memory Management

View full text Add to dashboard Cite

The garbage collector (GC) is a crucial component of language runtimes, offering correctness guarantees and high productivity in exchange for a run-time overhead. Concurrent collectors run alongside application threads (mutators) and share CPU resources. A likely point of contention between mutators and GC threads and, consequently, a potential overhead source is the shared last-level cache (LLC).This work builds on the hypothesis that the cache pollution caused by concurrent GCs hurts application performance. We validate this hypothesis with a cache-sensitive Java micro-benchmark. We find that concurrent GC activity may slow down the application by up to 3 × and increase the LLC misses by 3 orders of magnitude. However, when we extend our analysis to a suite of benchmarks representative for today's server workloads (Renaissance), we find that only 5 out of 23 benchmarks show a statistically significant correlation between GC-induced cache pollution and performance. Even for these, the performance overhead of GC does not exceed 10 %. Based on further analysis, we conclude that the lower impact of the GC on the performance of Renaissance benchmarks is due to their lack of sensitivity to LLC capacity. CCS Concepts:• Software and its engineering → Runtime environments; Garbage collection; • Computer systems organization → Multicore architectures.

show abstract

Section: Challengesmentioning

confidence: 99%

Section: Challengesmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Concurrent GCs and Modern Java Workloads: A Cache Perspective

Carpen-Amarie¹,

Vavouliotis²,

Tovletoglou³

et al. 2023

Proceedings of the 2023 ACM SIGPLAN International Symposium on Memory Management

View full text Add to dashboard Cite

show abstract

“…Figure 7 presents a lower bound overhead (LBO) analysis of LXR, G1, Shenandoah, ZGC, and OpenJDK's two stop-theworld collectors, Serial and Parallel. Cai et al introduced the LBO methodology as a way of placing an emperical lower bound on the overheads introduced by garbage collectors [13].…”

Section: Lbo Analysismentioning

confidence: 99%

“…Figure 7. Lower bounds on collector overheads averaged over all benchmarks, relative to a notionally ideal collector following the LBO methodology[13]. Each line represents the average overhead over all benchmarks for 40 invocations.…”

mentioning

confidence: 99%

Low-Latency, High-Throughput Garbage Collection (Extended Version)

Zhao,

Blackburn,

McKinley

2022

Preprint

View full text Add to dashboard Cite

To achieve short pauses, state-of-the-art concurrent copying collectors such as C4, Shenandoah, and ZGC use substantially more CPU cycles and memory than simpler collectors. They suffer from design limitations: i) concurrent copying with inherently expensive read and write barriers, ii) scalability limitations due to tracing, and iii) immediacy limitations for mature objects that impose memory overheads.This paper takes a different approach to optimizing responsiveness and throughput. It uses the insight that regular, brief stop-the-world collections deliver sufficient responsiveness at greater efficiency than concurrent evacuation. It introduces LXR, where stop-the-world collections use reference counting (RC) and judicious copying. RC delivers scalability and immediacy, promptly reclaiming young and mature objects. RC, in a hierarchical Immix heap structure, reclaims most memory without any copying. Occasional concurrent tracing identifies cyclic garbage. LXR introduces: i) RC remembered sets for judicious copying of mature objects; ii) a novel low-overhead write barrier that combines coalescing reference counting, concurrent tracing, and remembered set maintenance; iii) object reclamation while performing a concurrent trace; iv) lazy processing of decrements; and v) novel survival rate triggers that modulate pause durations.LXR combines excellent responsiveness and throughput, improving over production collectors. On the widely-used Lucene search engine in a tight heap, LXR delivers 7.8× better throughput and 10× better 99.99% tail latency than Shenandoah. On 17 diverse modern workloads in a moderate heap, LXR outperforms OpenJDK's default G1 on throughput by 4% and Shenandoah by 43%.

show abstract