Shenandoah GC: The Next Generation
summary
Shenandoah GC implements concurrent marking and concurrent compaction with Brooks pointer indirection, SATB write barriers and read barriers to keep pause times low; an example log shows concurrent mark ~1 s, evacuation ~400 ms, update ~400 ms while pauses stay below 1 ms. Runtime uses pacing (default 10 ms pacing) and a degenerate GC fallback before a full stop-the-world compaction. Heap overhead is one extra word per object (practical overhead ≈ 1.05×), trading small memory/CPU cost for millisecond-scale latency.
AI-written summary · about
chapters (25)
- 0:00Shenandoah GC intro
- 1:32Why concurrent GC matters
- 3:40Shenandoah origins & uses
- 5:04Shenandoah releases & compat
- 6:10Heap regions in Shenandoah
- 8:38Marking phase & three-color
- 11:47Snapshot at beginning & barriers
- 14:41Copying phase & Brooks pointers
- 17:58Write barriers & two-space
- 20:28Read barriers & performance
- 22:55Barrier comparisons & cases
- 23:59Portability across systems
- 25:03Generational hypothesis & LRU
- 26:28Benchmarking Shenandoah LRU
- 28:37Time comparison with other GCs
- 30:01Command & control in GC
- 31:48Heap expansion strategies
- 33:56Heap sizing policies
- 36:41Footprint vs CPU trade-offs
- 38:05Pacing allocating threads
- 41:59Degenerate GC & failures
- 44:31Incremental vs abrupt failures
- 45:36Choosing the right GC
- 46:41Shenandoah releases & resources
- 47:30Q&A pacing & pauses
related talks
29mShenandoah 2 0: Now That We’ve Gotten the GC Pause Times Under Control, What’s Next?
56mShenandoah: The Garbage Collector That Could
47mConcurrent Garbage Collectors: ZGC & Shenandoah
49mConcurrent Garbage Collectors: ZGC & Shenandoah
01h 01mOpenJDK: In the new age of Concurrent Garbage Collectors
50mUnderstanding Low Latency JVM GCs
01h 07mShenandoah – ultra-low Pause Time Garbage Collector #underthehood
15mThree flavors of generational GC: G1, ZGC, Shenandoah
