Building the Next-Generation Garbage Collector in Ruby
summary
MMTk integration for Ruby now matches the default GC’s speed after adding moving Imix, a bump-pointer fast path and a Ruby heap growth policy. Benchmarks show single-threaded marking 38.5ms vs 16‑core parallel 11.9ms (≈3× speedup), the fast-path allocation yields ~4% faster string allocation, and switching from MMTK’s dynamic heap to the Ruby heap cuts an ActiveRecord run from 845ms to 233ms (default GC still 148ms).
AI-written summary · about
chapters (21)
- 0:00Introduction
- 1:26Ruby GC limitations
- 6:18Modular GC features
- 7:44MMTK introduction
- 8:26MMTK algorithms
- 9:08MMTK parallelism
- 11:39Dynamic object sizes
- 12:21MMTK improvements
- 12:42Imix benefits
- 13:45Imix in MMTK
- 14:27Bump pointer allocator vs free list allocator
- 15:50Bump pointer fast path
- 18:57Heap growth algorithms
- 20:00Ruby heap benchmarks
- 22:54MMTK future improvements
- 23:15Generational garbage collection and sticky mark bit
- 26:24Enhancing MMTK parallelism
- 27:28Dynamic allocation optimization
- 28:10JIT fast path inlining
- 29:14Summary
- 29:55Q&A
related talks
30mBuilding the Next-Generation Garbage Collector in Ruby
40mMemory management with MMTk: lessons learned from replacing Ruby's garbage collector
34mUnder the Hood of Ruby's Generational Garbage Collector
42mTweaking Ruby GC Parameters for Fun, Speed, and Profit
33mRails and the Ruby Garbage Collector: How to Speed Up Your Rails App
21mUnderstanding Garbage Collection in Ruby
38mWhy I am excited about Ruby 2.1?
34mIt's dangerous to GC alone. Take this!