Files
ruby/gc
Matt Valentine-House 37561263fc ZJIT: Make the write barrier marking flag per-objspace
`zjit_during_incremental_marking` was one process-wide global, written
by `gc_set_incremental_marking` on every transition of any objspace.
Since 24be314b45, two objspaces can run incremental marks at the same
time, so when one finished its mark it wrote zero while another was
still marking.

`gen_write_barrier` skips `rb_gc_writebarrier` when the receiver is young,
not shareable, and the word reads zero, so JIT code in the still-marking
objspace skipped the barrier.

A white object stored into a young black receiver was never marked, the
sweep freed it, and the next major crashed with

```
[BUG] try to mark T_NONE object (parent: T_ARRAY/Array).
```

This bug can be reproduced in a few seconds with

```
RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=0.5 ./ruby --zjit test.rb, where test.rb is:
```

```
Ractor.new {
  loop {
    GC.start(full_mark: true, immediate_mark: false, global: false)
    GC.start(global: false)
  }
}

loop {
  GC.start(full_mark: true, immediate_mark: false, global: false)
  Array.new(2_000) { [nil] }.each { |b|
    200.times { Object.new }
    sleep 0.0002
    b[0] = Object.new
  }
}
```

Limiting the oldobject limit factor ensures we keep running majors which
makes this bug easier to trigger, and the array is pre-sized because the
inlined ArrayAset side-exits on an empty array.

This commit moves zjit_incremental_marking into rb_objspace_t and makes
it a bool, so each Ractor can signal to zjit when it's incrementally
marking. Because this is now directly addressable per objspace we've
also removed the incremental marking flag.
2026-10-19 13:46:08 +01:00
..

Ruby's Garbage Collectors

This directory contains implementations for Ruby's garbage collector (GC). The GC implementations use the Modular GC API to interact with Ruby. For more details about this API, see the Modular GC API section.

Two GC implementations are included in Ruby:

  • Default: The GC implementation that is used by default in Ruby. This GC is stable and production ready. The implementation uses a mark-sweep-compact algorithm.
  • MMTk: An experimental implementation using the MMTk framework. The code lives in the ruby/mmtk repository and is synchronized here. MMTk provides a wide variety of GC algorithms to choose from. For usage instructions and current progress, refer to the ruby/mmtk repository.

Building guide

Tip

If you are not sure how to build Ruby, follow the Building Ruby guide.

Important

Ruby's modular GC feature is experimental and subject to change. There may be bugs or performance impacts. Use at your own risk.

Building Ruby with Modular GC

  1. Configure Ruby with the --with-modular-gc=<dir> option, where dir is the directory you want to place the built GC libraries into.
  2. Build Ruby as usual.

Building GC implementations shipped with Ruby

  1. Build your desired GC implementation with make install-modular-gc MODULAR_GC=<impl>. This will build the GC implementation and place the built library into the dir specified in step 1. impl can be one of:
    • default: The default GC that Ruby ships with.
    • mmtk: The GC that uses MMTk as the back-end. See Ruby-specific details in the ruby/mmtk repository.
  2. Run your desired GC implementation by setting the RUBY_GC_LIBRARY=<lib> environment variable, where lib could be default, mmtk, or your own implementation (as long as you place it in the dir specified in step 1).

Modular GC API

Warning

The Modular GC API is experimental and subject to change without notice.

GC implementations interact with Ruby via the Modular GC API. All implementations must provide the functions in gc/gc_impl.h for Ruby to hook into. GC implementations can use any public C API in Ruby, along with additional APIs defined in gc/gc.h.

Additionally, create an extconf.rb file to build the GC library. This file must use gc/extconf_base.rb and the create_gc_makefile method.