Understanding Java Garbage Collection and what you can do about it
summary
Explains why pauses, not allocation efficiency, limit JVM scale and describes building a concurrent solution: C4 continuously concurrent compacting collector and the Zing JVM that implements it. Claims: a single-pass marker and concurrent compaction with no stop-the-world fallback, handling sustained allocation rates (examples show ~1.2 GB/s and 50+ GB heaps) and turning multi‑second pauses (14 s example) into millisecond events (20 ms). Uses JHiccup for latency measurement and cites a real app failure from pervasive finalizers to motivate the design.
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:23This Talk's Purpose / Goals
- 2:24About me: Gil Tene
- 4:16About Azul
- 6:41High level agenda
- 7:45Memory use
- 9:44What is Garbage Collection good for?
- 14:13The story of the good little architect
- 17:21Most of what people seem to "know" about Garbage Collection is wrong
- 21:14Trying to solve GC problems in application architecture is like throwing knives
- 23:28A Basic Terminology example: What is a concurrent collector?
- 25:00Classifying a collector's operation
- 27:02Precise vs. Conservative Collection
- 30:16Safepoints
- 33:35What's common to all precise GC mechanisms?
- 36:24Mark (aka "Trace")
- 45:40Generational Collection
- 51:49How does the remembered set work?
- 55:20The typical combos in commercial server JVMS
- 56:14Useful metrics for discussing
- 59:23Empty memory needs (empty memory == CPU power)
related talks
52mUnderstanding Java Garbage Collection
44mJava at Speed: Building a Better JVM.
01mThe evolution of Garbage Collection Algorithms in Java
49mTrash Talk: Exploring the JVM memory management
47mConcurrent Garbage Collectors: ZGC & Shenandoah
52mGarbage collection for the humans
49mConcurrent Garbage Collectors: ZGC & Shenandoah
35mJava at Speed: Building a Better JVM