Allocating an object on the managed heap is one of the cheapest operations in .NET — but "cheap" is not the same as "free."

You now know the GC reclaims garbage generationally, cheaply, in Gen0 most of the time. But there's a question sitting right behind that: how does new Customer() actually get its memory in the first place? In a language without a GC, allocation itself usually means asking a general-purpose allocator to search for a suitable free block — a real, sometimes-expensive operation. Does .NET do the same thing?

It doesn't — and the reason it doesn't is directly connected to everything you just learned about generations. Because Gen0 is compacted after every collection, allocating into it can be reduced to one of the simplest operations a computer can perform.

In this lesson, you'll see exactly how a Gen0 allocation happens, why it's so fast, and why "fast to allocate" still doesn't mean allocation has zero cost.

What Is It?

The Simple Explanation

Allocating a new object on Gen0 of the managed heap is, in the common case, just moving a pointer forward. The runtime keeps a marker — think of it as "the next free address" — and handing out memory for a new object is as simple as: check there's enough room, hand back the current marker's address, then advance the marker past the space just used. No searching for a free block, no bookkeeping about fragmented gaps — because after every Gen0 collection, the survivors are compacted (moved together), guaranteeing the free space is always one single contiguous region.

The Technical Definition

This technique is called bump-pointer (or bump allocation). It's only possible because the region being allocated into is guaranteed to have a single contiguous block of free space at its end — a guarantee that generational GC actively maintains through compaction, rather than something that happens to be true by luck. Contrast this with a general-purpose "free list" allocator (closer to what malloc typically does), which has to search among many scattered free blocks of varying sizes to find one that fits — real, variable-cost work that a bump allocator sidesteps entirely.

Why Does It Exist?

The Problem

A typical C# program, especially a web API or any application doing heavy LINQ or string work, allocates constantly — DTOs, intermediate LINQ collections, string interpolation results, closures. If each of those allocations required searching through a scattered free list for a suitably-sized gap, allocation itself would become a real, visible cost sprinkled throughout ordinary code — the opposite of what you'd want for a language that's meant to let you write natural, expressive code without obsessing over every allocation.

The Solution

Generational GC's compaction (from the previous lesson) isn't just about keeping collections cheap — it has a second, equally important payoff: it keeps Gen0's free space contiguous, which is exactly the precondition bump-pointer allocation needs. This is a deliberate, connected design: the GC does a bit of extra work during collection (moving survivors together) specifically so that allocation, which happens vastly more often than collection, can be as close to free as physically possible. It's a trade: pay a small, predictable cost during (infrequent) collection to make the (extremely frequent) allocation path nearly instantaneous.

Big Picture

How It Works

Step 1 — A reference type is allocated

var order = new Order(); // triggers a heap allocation

The runtime checks whether the current Gen0 allocation pointer, plus the size of an Order object, still fits within Gen0's budget. In the common case, it does.

Step 2 — The pointer is handed out and advanced

The memory address currently held by the allocation pointer becomes order's address. The runtime then advances the pointer forward by exactly the size of an Order object (including its object header — see below), so the very next allocation starts right after it. Conceptually, this is close to a single addition and a comparison — genuinely one of the cheapest operations in the entire runtime.

Step 3 — The object's header and fields are initialized

Every object gets a small fixed-size header (typically holding a pointer to its type's method table and some flags used by the runtime — for locking via lock, for hash code caching, and other bookkeeping). The runtime zeroes out the newly-claimed memory and then your constructor runs, setting the object's actual field values. The zeroing and construction cost is separate from — and typically larger than — the pointer-bump itself, which is worth keeping in mind: "allocation is a pointer bump" describes claiming the space, not the full cost of bringing a new object into existence.

Step 4 — Gen0 fills up; a collection restores contiguous space

Eventually the allocation pointer reaches the edge of Gen0's budget. A Gen0 collection runs (the previous lesson's topic), reclaiming garbage and compacting survivors into a tight, contiguous block. The allocation pointer is reset to sit right after that block — and the whole cycle of cheap bump allocations begins again against a freshly restored, fully contiguous free region.

Simple Example

public static List<string> FormatNames(List<Customer> customers)
{
    var results = new List<string>(); // 1 allocation (the List's internal array too)
    foreach (var c in customers)
    {
        // Each iteration: a new interpolated string is allocated,
        // then added — the List itself may also reallocate its
        // backing array as it grows past its current capacity.
        results.Add($"{c.FirstName} {c.LastName}");
    }
    return results;
}

What's happening allocation-wise:

• Every call to this method with, say, 1,000 customers performs roughly 1,000 small string allocations (plus the List<string> itself and its backing array) — every single one is a cheap Gen0 bump allocation.
• This is completely idiomatic, normal C#. You are not expected to avoid this pattern out of fear that "allocation is expensive" — for genuinely short-lived Gen0 objects like these, it usually isn't the bottleneck.
• What does matter: if this method runs millions of times per second under extreme load, the sheer volume of Gen0 collections it triggers (not the cost of any single allocation) is what eventually shows up in a profiler — this is the real cost worth understanding, covered next.

Real-World Example

A high-throughput JSON API deserializing thousands of requests per second is a good example of both sides of this lesson at once. Each request typically allocates: a DTO graph from deserialization, some LINQ intermediate sequences while validating or transforming the data, and a response object. Every one of those allocations is individually near-free thanks to bump allocation — no single line of that code is "slow" in isolation.

But multiply that by tens of thousands of requests per second, and the aggregate allocation rate becomes the actual variable that matters: it directly determines how often Gen0 fills up and needs collecting. A service allocating twice as much garbage per request will trigger roughly twice as many Gen0 collections under the same load — and while each Gen0 collection is individually cheap, at a high enough frequency, that adds up to real, measurable CPU time and can start contributing to tail latency. This is precisely why performance-sensitive .NET code (hot loops in a high-throughput service, not everyday business logic) sometimes reaches for allocation-reducing techniques like object pooling or Span<T> — tools for a later Advanced lesson — specifically to reduce collection frequency, not because any single allocation was expensive on its own.

Analogy

Under the Hood

Common Confusion

1. "Allocation is basically free in .NET, so allocate as much as you want without thinking"

This overstates the case. Any single allocation is extremely cheap compared to a general-purpose unmanaged allocator's free-list search — that part is genuinely true and well worth internalizing. But allocation still has real costs: object header overhead, constructor execution time, and — most importantly at scale — contribution to how often Gen0 (and, if survivors keep piling up, older generations) needs collecting. "Cheap per-allocation" and "free in aggregate at any volume" are different claims; only the first one is accurate.

2. "Bump-pointer allocation means .NET never has to search for free space"

This is true specifically for Gen0, precisely because compaction guarantees a single contiguous free region there. It is not true for the Large Object Heap, which — as you learned in the previous lesson — isn't compacted by default, and does track and reuse freed gaps rather than relying purely on a simple bump pointer. The "it's just a pointer bump" story is a Gen0-specific story, not a universal one across the entire managed heap.

3. "Fewer allocations always means better performance"

Not necessarily, and not automatically worth chasing everywhere. Contorting readable, idiomatic code to avoid ordinary short-lived allocations, without measurement, frequently isn't worth the loss in clarity — the whole point of generational GC's design is to make this pattern cheap so you don't have to avoid it reflexively. Allocation reduction is a targeted optimization for measured hot paths, not a default coding style to apply everywhere.

Common Mistakes

Mistake 1 — Prematurely eliminating allocations in ordinary business code

Rewriting a perfectly readable LINQ pipeline into a manual, allocation-avoiding loop for code that runs a handful of times per request, on the theory that "fewer allocations is always better."

Reserve allocation-conscious rewrites for code proven, through profiling, to be a genuine hot path. Elsewhere, prioritize readability — the GC is specifically engineered to make this the right default trade-off.

Mistake 2 — Treating "allocation is cheap" as "GC pauses don't matter"

Ignoring a high allocation rate in a genuinely hot, high-throughput path because "each allocation only takes a few nanoseconds."

Recognize that the aggregate allocation rate is what drives collection frequency — a high enough rate of cheap individual allocations still adds up to a real, measurable amount of total GC activity, which is exactly why it's worth profiling actual allocation volume, not just per-allocation cost, in hot paths.

Mistake 3 — Forgetting object header overhead when estimating memory usage

Calculating expected memory usage for a large collection of small wrapper objects purely by summing field sizes, and being surprised when actual usage is meaningfully higher.

Account for the fixed per-object header overhead, especially for collections of many small objects — this is one concrete reason a struct (no separate header, when not boxed) can be meaningfully more memory-efficient than an equivalent class for very small, high-volume data, a distinction the stack-vs-heap and boxing lessons build on directly.

Why Does This Matter for My Code?

You don't control the allocation mechanism directly — but understanding it correctly calibrates when allocation is genuinely worth optimizing:

• For the overwhelming majority of application code — request handlers, business logic, LINQ pipelines — write natural, idiomatic C#. The allocation cost of doing so is genuinely small, and the GC is specifically designed around this pattern being cheap.
• In a proven hot path (measured with a profiler, not guessed at), watch allocation rate, not individual allocation cost — that's the number that actually predicts GC pressure.
• When estimating memory footprint for large numbers of small objects, remember object header overhead — it's a real, fixed cost per instance that field-size math alone misses.
• This lesson sets up the next two directly: stack-vs-heap explains when you can avoid heap allocation altogether, and boxing explains one of the most common, easily-avoidable sources of unnecessary allocation in real codebases.

Mental Model

Key Takeaway

Check Your Understanding

You've learned how Gen0 allocation actually works, and why "cheap" isn't the same as "free." Let's check your understanding.

You now understand exactly how cheap — and how not-quite-free — heap allocation really is in .NET. Next: when a value doesn't need the heap at all.

dotnetmadeeasy.com — Learn C# and .NET, the right way.