Does RUBY_GC_MALLOC_LIMIT affect the frequency of Major GC cycles?

Short answer

No — not directly. In MRI/CRuby's generational collector, RUBY_GC_MALLOC_LIMIT controls the malloc-allocation threshold that triggers a minor (young-generation) GC. Major GC frequency is governed primarily by RUBY_GC_OLDMALLOC_LIMIT, plus old-generation heap growth and the promotion of surviving objects. Raising RUBY_GC_MALLOC_LIMIT makes minor GCs less frequent; it does not, by itself, change the threshold at which a Major GC fires.

The indirect effect

There is a real but indirect relationship, and it is workload-dependent:

• Objects that survive a minor GC can be promoted to the old generation. Once promoted, they contribute to the old-generation counters that eventually trigger a Major GC.
• Running minor GCs more often (lower malloc limit) reclaims short-lived objects sooner, which can reduce how many objects survive long enough to be promoted — potentially delaying Major GCs.
• Running minor GCs less often (higher malloc limit) lets more garbage accumulate per cycle. Each cycle processes a larger volume, as the question suggests, and promotion patterns can shift in either direction depending on object lifetimes.

So increasing RUBY_GC_MALLOC_LIMIT changes the volume per cycle and the minor-cycle cadence, but any change in Major GC frequency is a side effect of altered promotion behavior, not a direct control. You should not rely on it for that purpose.

What to tune instead

If the goal is fewer stop-the-world Major GC pauses, the relevant knobs are:

• RUBY_GC_OLDMALLOC_LIMIT — the old-generation malloc threshold that directly gates Major GC.
• Old-generation heap slot growth (RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR on versions that expose it).

All of these variables are read once at process start, are process-wide, and apply only to MRI/CRuby — JRuby and TruffleRuby use entirely different GC tuning mechanisms. Exact defaults and even which knobs exist vary across Ruby 2.1 through 3.x, so check the documented defaults for your specific version before tuning.

How to verify on your workload

GC.stat exposes the counters you need to separate minor from major cycles:

GC.stat.values_at(:count, :minor_gc_count, :major_gc_count)

Sample these before and after a representative workload run:

1. Baseline: record :major_gc_count and :minor_gc_count with default settings.
2. Change only RUBY_GC_MALLOC_LIMIT and re-measure. Expect :minor_gc_count to move; observe whether :major_gc_count shifts at all.
3. Change only RUBY_GC_OLDMALLOC_LIMIT and re-measure to isolate which knob actually moves Major GC frequency.

One caution: lowering RUBY_GC_MALLOC_LIMIT aggressively to suppress promotion increases total GC time and can hurt throughput even if Major GCs become rarer. Measure wall-clock time and pause distribution, not just cycle counts.

Uncertainty

The promotion behavior described above is well-established generational GC design in CRuby, but the magnitude of the indirect effect depends on your allocation profile. The verification steps above are the reliable way to confirm it for your application rather than assuming a directional effect.