Allocation Pressure & GC

## What the two methods do Ruby's `GC` module is the interface to CRuby's garbage collector. Two of its methods are the ones people reach for first. **`GC.start`** starts a collection immediately. Its keyword arguments and their defaults are: - `full_mark: true` - mark every object, old and young, which is a **major** collection; `false` asks for a **minor** one that marks only young objects; - `immediate_mark: true` - finish marking before returning instead of doing it incrementally; - `immediate_sweep: true` - finish sweeping before returning instead of lazily. So a bare `GC.start` is the most expensive collection CRuby can do, and the program waits for all of it. It returns `nil`. **`GC.disable`** stops automatic collection. It returns whether collection was **already** disabled, so the first call returns `false` and a second returns `true`. `GC.enable` reverses it and returns whether collection *had been* disabled. Its documentation adds one detail that surprises people: `GC.start` "remains potent" - an explicit `GC.start` still collects while automatic collection is off. ## Why application code should rarely call them CRuby already decides when to collect. A collection starts when, for example: 1. there are no free slots left for a new object; 2. memory allocated through `malloc` since the last collection crosses the malloc limit (16 MB initially, tunable with `RUBY_GC_MALLOC_LIMIT`); 3. the number of old objects crosses the old-object limit, which forces a major collection. Against that background: | Call in app code | What actually happens | |---|---| | `GC.start` after each request or job | a full, blocking collection that the runtime would have done more cheaply, or not at all | | `GC.disable` around a heavy section | every object allocated in it stays in memory; the heap and RSS grow until `GC.enable` or an out-of-memory kill | | `GC.disable` and forgetting `GC.enable` | the process leaks memory for the rest of its life | Disabling collection does not make allocation free; it only postpones the bill, and the heap pages grown in the meantime are not necessarily handed back afterwards. ## Where they do belong - **Benchmarks** - a `GC.start` before each measured run gives every run the same starting heap; turning collection off for a short micro-benchmark removes GC noise, as long as you say so when reporting. - **Tests and diagnosis** - forcing a full collection before reading `GC.stat` or counting objects shows what is really still referenced. - **Controlled points in long-lived processes** - for example preparing a parent process before it forks workers, where a full collection (and often `GC.compact`) is done once, on purpose. ## Related methods worth knowing - `GC.count` - total number of collections so far, minor plus major. - `GC.stat` - a Hash of counters such as `:minor_gc_count`, `:major_gc_count` and `:total_allocated_objects`. - `GC.stress = true` - collect at every opportunity; its documentation says it degrades performance and is only for debugging. ## Summary `GC.start` forces a (by default full, blocking) collection; `GC.disable` suspends automatic collection and returns the previous state. The runtime already collects on its own triggers, so in production code the right number of calls to either is almost always zero.