Platinum: A CPU-Efficient Concurrent Garbage Collector
summary
Platinum implements a mostly-concurrent JVM GC that isolates mutators and GC threads by binding GC threads to cores and moving mutators to idle-core pinning, partitions heap into collection/pinned/allocation regions to keep mutators out of collector working set, and replaces software write barriers with an MPK-based protection that triggers a page fault and handler for out-of-region writes. Built in OpenJDK and evaluated on an 80-core machine against G1, Shenandoah and CMS, it cuts 99th-tail latency up to 79.3% while keeping CPU overhead moderate, with <1 ms init pauses and ~10 ms final updates.
AI-written summary · about
chapters (18)
- 0:00Intro
- 0:24A page is multiple services
- 2:13GC Pauses Introduce The Long Tail Problem
- 2:58Alternative Design: Concurrent GC
- 4:07Concurrent GC Is Not Always Helpful
- 5:47Why Are Concurrent Collectors Inefficient?
- 7:10Opportunities: Idle Cores in GC
- 8:05Opportunities: Skewed Write Behavior
- 9:14Opportunities: MPK
- 9:55Our Design: Platinum
- 10:36Design Overview
- 11:03Idle Core Collection
- 11:40Heap Partition
- 12:47Hardware-Assisted Barrier Elimination
- 15:52Cassandra
- 16:40Coupon
- 17:01CPU Utilization Under Stressful Workload
- 17:37Conclusion
related talks
44mGarbage Collector: How to Tame the Beast and Make It Your Best Ally
01h 01mOpenJDK: In the new age of Concurrent Garbage Collectors
47mConcurrent Garbage Collectors: ZGC & Shenandoah
19mZ Garbage Collector: The Next Generation
49mConcurrent Garbage Collectors: ZGC & Shenandoah
01h 32mUnderstanding Java Garbage Collection and what you can do about it
25mGarbage Collection Primer
50mTrash Talk - Exploring the JVM memory management