The one allocation the garbage collector will never, ever see — because it isn't on the heap at all.

Back in Advanced Part I, the stack-vs-heap lesson mentioned stackalloc in a single forward-looking paragraph and then deliberately moved on, promising "a dedicated Advanced module later." This is that module. You now have everything you need to understand it properly: precisely how the stack reclaims memory (last lesson's whole topic), and exactly what a ref struct is and why it's the safe wrapper around what stackalloc produces (the previous lesson).

stackalloc is the one allocation mechanism in all of C# that has genuinely nothing to do with the garbage collector — not "rarely collected," not "usually cheap to collect" — never tracked by the GC at all, because it never touches the managed heap in the first place.

In this lesson, you'll learn exactly what stackalloc allocates and where, the modern span-wrapped syntax that makes it safe to use in ordinary code, genuine real-world use cases for it, and the one real danger — stack overflow — that makes it a tool you reach for deliberately, not by default.

What Is It?

The Simple Explanation

stackalloc allocates a block of memory directly on the current method's own stack frame — the exact same region of memory that already holds your local ints and decimals, per the mental model from two lessons ago. It is reclaimed the instant the method returns, automatically, with zero GC involvement — exactly like every other local value-type variable.

The Technical Definition

stackalloc is a C# operator that reserves a contiguous block of uninitialized (or, for value types, zero-initialized by default) memory on the calling method's stack frame, and produces either a pointer to that memory (the original, unsafe-only syntax) or a Span<T>/ReadOnlySpan<T> wrapping it (the modern, safe syntax introduced in C# 7.3). Because that memory is not tracked by the garbage collector at all — it isn't part of any generation, it has no object header, it's never scanned during a collection — using stackalloc produces genuinely zero heap allocation for that buffer.

Why Does It Exist?

The Problem

Some hot-path code needs a small, short-lived scratch buffer — a handful of bytes to build a hash, a few dozen characters to format a number, a temporary staging area while parsing. The obvious tool is new byte[64], but that's a heap allocation: it goes through the allocator, gets an object header, gets tracked by Gen0, and eventually has to be traced and collected — real, if individually small, work for the GC, as the Generational GC lesson in Advanced Part I covered in detail. In a method called millions of times per second, thousands of these tiny, disposable arrays add up to real, measurable GC pressure, purely for memory that's used for microseconds and then thrown away.

The Solution

If a buffer's entire lifetime fits neatly within one method call — allocated at the top, used and discarded before the method returns — it has exactly the lifetime profile the stack already handles for free, as the previous stack-vs-heap lesson established. stackalloc lets you deliberately put that buffer there instead of the heap: reclamation is automatic and instantaneous on return, with zero tracing, zero collection, and zero GC pressure whatsoever — the fastest possible way to get temporary memory in .NET, precisely because it sidesteps the garbage collector entirely rather than merely being cheap for it to collect.

Big Picture

How It Works

The modern, idiomatic syntax

Span<byte> buffer = stackalloc byte[256];

buffer[0] = 0xFF;          // bounds-checked, safe indexing
buffer.Fill(0);            // ordinary Span<T> API, no unsafe code
var slice = buffer[..16];  // slicing works exactly as it does for any Span<T>

Notice that buffer is typed as Span<byte> — a ref struct, per the previous lesson. That's not incidental: it's the exact mechanism that makes this safe. Because Span<T> can never be boxed, stored in a field, captured by a closure, or held across an await, the compiler guarantees this stack-allocated buffer can never be smuggled somewhere it would outlive the stack frame it lives on. The ref struct restrictions from the last lesson exist largely because of exactly this scenario.

The legacy, unsafe syntax — for context, not for regular use

unsafe
{
    byte* buffer = stackalloc byte[256];
    buffer[0] = 0xFF; // no bounds checking — buffer[9999] compiles and corrupts memory silently
}

This is the original stackalloc syntax, predating Span<T> (which arrived in C# 7.2/7.3). It requires an unsafe context, gives you a raw pointer with no bounds checking at all, and you'll still encounter it in older codebases and in genuinely low-level unsafe interop code. For virtually all new code, prefer the Span<T>-wrapped form — you get identical stack-allocation behavior with real safety on top, at no performance cost.

Simple Example — formatting a number without allocating a string

public static void WriteFormattedId(int id, TextWriter writer)
{
    Span<char> digits = stackalloc char[10]; // int.MaxValue has 10 digits, max

    if (id.TryFormat(digits, out int written))
    {
        writer.Write(digits[..written]);
    }
}

Why this avoids allocation entirely: int.TryFormat writes the formatted digits directly into the span-wrapped stack buffer — no intermediate string is ever allocated on the heap just to hold the digits before writing them out. Compare this to the far more common writer.Write(id.ToString()), which allocates a new heap string on every single call. For a method called millions of times, that's a real, measurable difference in GC pressure for a code path that gains nothing lasting from the allocation — the string exists for microseconds and is immediately discarded.

Real-World Example — a bounded, safe hashing buffer with an ArrayPool fallback

Real production code almost never uses a fixed-size stackalloc blindly — it uses a small, safe threshold, and falls back to ArrayPool<T> (covered elsewhere in this Part) for anything larger:

private const int StackAllocThreshold = 256;

public static string ComputeHash(ReadOnlySpan<byte> data)
{
    Span<byte> hashBuffer = stackalloc byte[32]; // SHA-256 output is always exactly 32 bytes — safe, fixed

    if (data.Length <= StackAllocThreshold)
    {
        Span<byte> scratch = stackalloc byte[StackAllocThreshold];
        data.CopyTo(scratch);
        SHA256.HashData(scratch[..data.Length], hashBuffer);
    }
    else
    {
        // Too large for a safe stack buffer — rent from the pool instead
        byte[] rented = ArrayPool<byte>.Shared.Rent(data.Length);
        try
        {
            data.CopyTo(rented);
            SHA256.HashData(rented.AsSpan(0, data.Length), hashBuffer);
        }
        finally
        {
            ArrayPool<byte>.Shared.Return(rented);
        }
    }

    return Convert.ToHexString(hashBuffer);
}

Notice the pattern: the stackalloc size is a small, fixed, compile-time-known constant (StackAllocThreshold, 256 bytes) — never sized directly by data.Length, which could be arbitrarily large if it ultimately traces back to user input. Anything above the threshold is routed to ArrayPool<T> instead, which can safely handle any size without risking the stack. This threshold-plus-fallback shape is the standard, idiomatic way real .NET code (including parts of the BCL itself) uses stackalloc safely.

Analogy

Under the Hood — the real danger: stack overflow

Common Confusion

1. "stackalloc always requires unsafe code"

Only the legacy raw-pointer form does. The modern Span<byte> buffer = stackalloc byte[256]; form requires no unsafe keyword whatsoever and has been the idiomatic way to write this since C# 7.3 — the safety comes from the ref struct guarantees of Span<T>, covered in the previous lesson.

2. "A StackOverflowException is like any other exception — just wrap it in try/catch"

This is the single most important correction in this lesson: it cannot be caught. Ever. By anything. A stack overflow terminates the process on the spot. This is fundamentally different from every other exception you've worked with across this entire course, and it's precisely why the size discipline in this lesson matters so much more than it would for an ordinary recoverable error.

3. "stackalloc memory is garbage collected, just very quickly"

No — it isn't garbage collected at all, at any speed. "Very fast collection" and "no collection involved whatsoever" sound similar but aren't the same thing. stackalloc memory is never part of any GC generation, is never traced, and is never subject to a collection pause. It's reclaimed purely by the stack pointer moving back when the method returns — the exact same zero-GC mechanism as any other local variable, as the previous lesson established.

Common Mistakes

Mistake 1 — Sizing a stackalloc directly from user or request input

Span<byte> buffer = stackalloc byte[userSuppliedLength]; — if userSuppliedLength comes from anywhere an attacker or careless caller could influence, this is a genuine, process-crashing denial-of-service vector, not just a bug.

Clamp against a small, safe constant threshold, and route anything larger to ArrayPool<T> — never trust an external value as a stack allocation size directly.

Mistake 2 — Calling stackalloc inside a loop, growing the live stack footprint each iteration

Placing a stackalloc inside a for loop body when the buffer isn't actually needed fresh each iteration, or inside recursive calls without a hard depth limit — each nested call's buffer stacks on top of the last, un-reclaimed until that specific call returns.

Hoist a single stackalloc above the loop when one reusable buffer will do, and always cap recursion depth explicitly when a recursive method also uses stackalloc.

Mistake 3 — Reaching for stackalloc as a default "faster than new[]" habit

Replacing every small array allocation in a codebase with stackalloc on the assumption that it's simply, unconditionally better.

Reserve it for genuinely hot, measured paths with small, provably bounded sizes — for ordinary code, a small heap array is simple, safe by construction, and the GC handles Gen0 garbage cheaply anyway (per the Generational GC lesson). The next two lessons in this Part cover exactly how to know whether a path is hot enough to deserve this treatment in the first place.

When Should I Use It?

Mental Model

Key Takeaway

Check Your Understanding

You now understand exactly where stackalloc memory lives, how to use it safely, and precisely what can go wrong. Let's confirm it.

You've delivered on the promise from Advanced Part I — you now know exactly what stackalloc allocates, how to use it safely, and precisely why its one real danger demands real discipline. Next, you'll pull every tool from this Part together into one coherent, zero-allocation programming style.

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