MMTk and The Case for Modular VM Development
summary
Argues that measured GC cost is misleading and introduces a distillation/elbow method that produces a lower bound on collector overhead; shows MMTk reimplemented in Rust as a modular, VM‑agnostic toolkit with bindings for OpenJDK, Julia and Ruby and a compact work‑packet scheduler for parallel GC work; reports that a new collector (LXR) is implemented in 19 weeks on MMTk, uses high‑performance reference counting with opportunistic copying, and outperforms G1, Shenandoah and ZGC on both latency and throughput across tight and large heaps.
AI-written summary · about
chapters (33)
- 0:00Introduction
- 3:18Is GC really solve a problem
- 5:48Simple GCS
- 6:30Costs
- 8:27Distillation
- 12:28Lower Bound Overhead
- 13:19Metrics
- 14:49Timespace tradeoff
- 18:41A surprise
- 21:22How did this happen
- 24:15Lack of innovation
- 26:49RIP Tread Brooks
- 27:21Modular VM Development
- 29:35Abstraction
- 30:46abstraction without guilt
- 31:37digression
- 36:13Results
- 37:43Successes
- 39:03Garbage Collector in Rust
- 40:02Motivations
- 41:22Design Approach
- 42:40Current Status
- 44:35Highlights
- 47:17OpenJDK
- 49:06Object Scanning
- 50:05Field Barrier
- 51:05Right Barriers
- 53:34Ruby
- 54:26Performance
- 56:21Latency
- 57:05Latency Graph
- 57:38The Punch Line
- 58:17Summary
related talks
15mUsing MMTk Garbage Collection in GHC (Lightning Talk)
34mModular Storage Mode Analysis
34mIt's dangerous to GC alone. Take this!
15mA Modular Cost Analysis for Probabilistic Programs
40mJoy of Meta-Tracing Just-in-Time Compilation: More Than Just a VM Generator
48mOne VM To Rule Them All
30mCompositional Deep Argument Flattening
01h 13mTalk by I-Ting Angelina Lee (Washington University in St. Louis)