How should we evaluate garbage collectors?
summary
Argues current GC evaluation fixes heap sizes and reports throughput but misses system dynamics, supported by 34 papers surveyed showing 28 used DaCapo and default heaps with geometric mean 63 MB; common methodology scales up to 6x min-heap yet on 16–64 core machines 75% of configs use <1% of machine memory. Shows OpenJDK G1 baseline, compares LXR/SGC/Parallel across default vs large workloads (large shifts results by up to ~20–30%), adds OpenJDK CPU logging (JDK26) and proposes deployment‑based representative heaps.
AI-written summary · about
chapters (8)
- 0:00GC evaluation introduction
- 1:53Java GC evaluation methods
- 8:55Hardware configurations
- 15:25DaCapo benchmarks heat map
- 25:26Default vs large workloads
- 39:53Reproducing SpecJBB 2015
- 46:21GC evaluation improvements
- 56:01Q&A
related talks
30m“Show Me the Garbage!”, Understanding Garbage Collection
54mThe `-ilities` of Software Engineering - How Qualities...
27mThe Mutability Matrix of Pain
01h 04mWe Live in Interesting Times
45mThe Joy of Building Large Scale Systems
17mWork Packets: A New Abstraction for GC Software Engineering, Optimization, and(…)
01h 01mWhat Programmers Should Know About Memory Allocation
30mBuilding the Next-Generation Garbage Collector in Ruby