https://github.com/ruby/mmtk/commit/9f730cc709

Adds MMTK_HEAP_MODE=cpu, a dynamic heap-sizing policy that grows
or shrinks the heap after each GC cycle to keep measured GC CPU
overhead near a configurable target. The control law follows
Tavakolisomeh et al., 'Heap Size Adjustment with CPU Control', MPLR
'23: a sigmoid of the (averaged) GC CPU overhead error in (-inf, +inf)
maps to a heap-size adjustment factor in (0.5, 1.5).

Implementation lives alongside the existing 'ruby' delegated trigger
in gc/mmtk/src/heap/. T_GC is wall-clock GC duration; T_APP is process
CPU time delta read via clock_gettime(CLOCK_PROCESS_CPUTIME_ID), which
correctly credits multi-threaded mutator parallelism. Nursery-only
generational GCs are skipped so the trigger only re-sizes at full
collections.

Configuration:

  MMTK_GC_CPU_TARGET   target GC CPU overhead, percent. Default 5.
  MMTK_GC_CPU_WINDOW   number of recent cycles averaged. Default 3.

The default differs from the paper's recommended 15. The paper
targets ZGC, a concurrent generational collector; MMTk-Ruby currently
ships stop-the-world Immix, where every percent of GC CPU also blocks
the mutator. An empirical sweep of MMTK_GC_CPU_TARGET across
ruby-bench (railsbench, lobsters, psych-load, liquid-render, lee)
found 5-6 to be Pareto-optimal vs the existing 'ruby' heap mode:
about 6 percent geomean throughput improvement at essentially equal
peak RSS. Targets >=10 trade large amounts of throughput for modest
RSS savings on this collector.

bin/smoke-test, bin/ruby-mmtk-mode, bin/compare-heap-modes, and
doc/testing-cpu-heap-mode.md are included so reviewers and future
contributors can reproduce the sweep against ruby/ruby-bench.

https://github.com/ruby/mmtk/commit/1f223f5ad5

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

https://github.com/ruby/mmtk/commit/a46b68fe5b

the only caller of this unconditionally constructs a binding options
object now, So actually this is dead code

https://github.com/ruby/mmtk/commit/d832004e89

This is a debug mode in Ruby where an extra word is used after each
object to store the address of the Ractor that owns the object, used for
debug purposes only.

While we're working on Ractors, we also need to be able to test with
MMTk enabled, so we should introduce support for this to the MMTk
binding as well.

As implemented we'll default the binding options to have everything
disabled and hardcoded to 0, as was always the case, but if
RACTOR_CHECK_MODE is enabled, we'll build and pass a valid RubyBinding
object to MMTk.

https://github.com/ruby/mmtk/commit/83cb291313

Outputs the number of GC cycles that are moving.

https://github.com/ruby/mmtk/commit/fef8f04186

https://github.com/ruby/mmtk/commit/7889da7c0e

Instead of sending all 128 buffered objects to one bucket,
round-robin distribute them across all worker buckets so
parallel obj_free work stays balanced.

https://github.com/ruby/mmtk/commit/e1f926cd21

https://github.com/ruby/mmtk/commit/26ec9f7f89

Previously, every object allocation in rb_gc_impl_new_obj made a
per-object FFI call into Rust (mmtk_add_obj_free_candidate), which
acquired a mutex on one of the WeakProcessor's candidate vecs, pushed a
single element, and released the mutex. That's an FFI crossing + mutex
lock/unlock on every single allocation.

Now, each MMTk_ractor_cache has two local buffers (parallel-freeable and
non-parallel-freeable, 128 entries each). On allocation, we just store
the pointer into the local buffer. When a buffer fills up, we flush the
entire batch in one FFI call using mmtk_add_obj_free_candidates, which
does a single mutex acquisition and extend_from_slice for the whole
batch.

We picked 128 as our buffer size at random. We should probably
investigate further what an optimum size for this is

https://github.com/ruby/mmtk/commit/23c4a9a676