How does generational garbage collection work in .NET, and why does it make most collections cheap?

1. The cost model in one formula

Approximate cost of a compacting young GC:

cost ≈ (roots scanned) + (dirty cards scanned) + (bytes of surviving objects copied) + (references updated)

Note what is missing: the number of dead objects. This is the entire reason generational, compacting collectors win for allocation-heavy managed code. Contrast with malloc/free, where every dead object costs a free call.

2. Allocation is a pointer bump

Each thread owns an allocation context: a small chunk of Gen 0 space with an alloc_ptr and alloc_limit.

Gen 0 region
+----------------------------------------------------------+
| obj | obj | obj | obj |  free in this allocation context  |
+----------------------------------------------------------+
                        ^alloc_ptr                ^alloc_limit

new in the fast path is roughly:

// pseudo-code of the JIT allocation helper fast path
if (alloc_ptr + size <= alloc_limit)
{
    obj = alloc_ptr;
    alloc_ptr += size;
    obj->MethodTable = mt;   // memory is already zeroed
    return obj;
}
return SlowPathAllocate(size); // get a new allocation context, maybe trigger a GC

The slow path takes a new chunk, and when the Gen 0 budget for this GC cycle is used up, it triggers a Gen 0 GC. The budget is dynamic: the GC tunes it from survival rates and cache sizes.

3. What the JIT contributes: GC info and safe points

The GC must know exactly which stack slots and registers hold object references. The JIT emits GC info for every method describing live references at each safe point. That is how .NET can be a precise (not conservative) collector, and why it can move objects: it knows every reference to update.

Thread suspension works by getting each thread to a safe point (at a call return, via return-address hijacking, or by polling in loops) before the GC begins.

4. The write barrier in practice

This C#:

_cache.LastItem = item; // _cache lives in Gen 2, item is new

compiles to IL stfld. The JIT does not emit a plain mov; it emits a call to a write barrier helper, conceptually:

JIT_WriteBarrier(&_cache.LastItem, item):
    *dst = item
    if item is in the ephemeral range (Gen 0/1):
        card_table[dst >> card_shift] = 0xFF   // mark card dirty

There are several barrier variants the runtime swaps in (precise vs non-precise, with or without software write watch for background GC). Two practical consequences:

• Writes of references into heap objects cost a few extra instructions. Writes of int or into locals do not.
• Structs containing references stored into arrays also trigger barriers (one per reference field).

5. Mark, plan, relocate, compact

Before Gen 0 GC (one Gen 0 region)
[A][x][x][B][x][x][x][C][x][x]     A, B, C reachable; x garbage

After compaction
[A][B][C][          free           ]
          ^ promoted to Gen 1 (or the region itself is reassigned)

• Mark: set a mark bit on each reachable object (in the object header/method table pointer bits).
• Plan: build a plan of where each survivor will move, using a brick table to find objects quickly, and decide compact vs sweep.
• Relocate: rewrite every reference (in stacks, handles, other objects) to the new addresses.
• Compact: move the bytes.

The GC decides compact vs sweep each time. Sweep is faster for the GC itself but leaves fragmentation (free list holes); compaction costs copying but gives future allocations contiguous space.

6. Segments vs regions

You can still opt back to segments with configuration (clrgc.dll / DOTNET_GCName) for diagnosis, but regions are the default and the right choice.

7. GC triggers

The GC may also escalate a requested generation (for example a Gen 1 becomes Gen 2) based on its tuning.

8. Version notes

9. Try it yourself

1. Run the code example and confirm the survivor moves 0 → 1 → 2 while the loop only increments the Gen 0 count.
2. Run dotnet-counters monitor -n YourApp System.Runtime against a small ASP.NET Core app under load (bombardier or k6), and note Gen 0/1/2 rates and % time in GC.
3. Add a static List<byte[]> that keeps every tenth allocation for 30 seconds. Watch Gen 2 count and heap size climb.
4. Call GC.GetGCMemoryInfo(GCKind.Ephemeral) and GCKind.FullBlocking and compare PauseDurations.
5. Collect a trace with dotnet-trace collect --profile gc-verbose and open it in PerfView's GCStats view; find the trigger reason for each GC.
6. Write a micro-benchmark with BenchmarkDotNet and [MemoryDiagnoser] that writes references into a long-lived array versus a local array; compare timings to see write barrier cost.

var survivor = new byte[100];
Console.WriteLine($"New object generation: {GC.GetGeneration(survivor)}");   // 0

GC.Collect(0);
Console.WriteLine($"After Gen 0 GC: {GC.GetGeneration(survivor)}");         // 1

GC.Collect(1);
Console.WriteLine($"After Gen 1 GC: {GC.GetGeneration(survivor)}");         // 2

int gen0Before = GC.CollectionCount(0);
int gen2Before = GC.CollectionCount(2);

// Short-lived garbage: dies in Gen 0
for (int i = 0; i < 1_000_000; i++)
{
    var temp = new byte[64];
    temp[0] = (byte)i;
}

Console.WriteLine($"Gen 0 GCs during loop: {GC.CollectionCount(0) - gen0Before}");
Console.WriteLine($"Gen 2 GCs during loop: {GC.CollectionCount(2) - gen2Before}");

GCMemoryInfo info = GC.GetGCMemoryInfo();
Console.WriteLine($"Heap size: {info.HeapSizeBytes:N0} bytes, pause time so far: {GC.GetTotalPauseDuration().TotalMilliseconds:N1} ms");
GC.KeepAlive(survivor);

GC.Collect is used here only to demonstrate promotion; do not call it in production code.