February 23, 2026 Ruby has traditionally shipped with a single, built-in garbage collector tightly coupled to the VM. With Ruby 3.4, that assumption begins to change. Feature #20470 introduces an experimental Modular Garbage Collector API, allowing CRuby to load alternative GC implementations at runtime. This marks one of the most significant architectural shifts in Ruby’s…

The RubyLA blog offers insights, tutorials, and community updates for Ruby developers in Los Angeles and beyond. Developers can explore Ruby language features, web development frameworks, and best practices for building Ruby applications. Additionally, the blog covers Ruby meetups, events, and job opportunities in the Los Angeles area, fostering collaboration and networking within the local Ruby community.

RUBYLAND

Ruby 3.4 introduces an experimental Modular Garbage Collector API (Feature #20470) that decouples the GC from the VM, allowing alternative GC implementations to be loaded at runtime via dynamic libraries. Two implementations ship with Ruby 3.4: the traditional default GC (modularized) and an experimental MMTk-based collector supporting advanced algorithms like Immix and concurrent collection. The active GC can be selected via the RUBY_GC_LIBRARY environment variable and queried through GC.config[:implementation]. While not production-ready or enabled by default, this architecture enables faster GC innovation, workload-specific tuning, and potential pauseless collectors without forking Ruby itself.

🧠 Pluggable Garbage Collectors in Ruby: Exploring the New Modular GC API

From Monolithic GC to Pluggable Architecture