How do you use stackalloc safely in modern C#? Explain stackalloc into Span<T>, the unmanaged type requirement, stack size limits and why a stack overflow kills the process, the hybrid stackalloc-or-ArrayPool pattern, why you must not stackalloc in loops, SkipLocalsInit, and how to choose a threshold.

How I would answer this in an interview

stackalloc allocates a block of memory on the current thread's stack, which is freed automatically when the method returns — no GC involvement. In modern C# you assign it to a Span<T>, which keeps it memory-safe (bounds checked, no pointers). It's excellent for small, bounded, temporary buffers. The danger is that the stack is small and a stack overflow kills the process, so safe usage means capping the size and falling back to ArrayPool<T>, never allocating in loops, and understanding SkipLocalsInit.

1. stackalloc into Span<T>

Span<byte> hash = stackalloc byte[32];                  // SHA-256 output
SHA256.HashData(input, hash);
string hex = Convert.ToHexString(hash);

Span<char> buffer = stackalloc char[64];
if (value.TryFormat(buffer, out int written, "N2", CultureInfo.InvariantCulture))
    writer.Write(buffer[..written]);

• No unsafe keyword needed when assigning to a Span<T>/ReadOnlySpan<T> (C# 7.2+).
• The span is a ref struct, so it can't escape the method (can't be returned, stored or used across await).
• Since C# 8, stackalloc can be used in nested expressions (Span<int> s = n < 128 ? stackalloc int[n] : new int[n];).

2. The unmanaged type requirement

The element type must be unmanaged: primitives, enums, pointers, or structs containing only unmanaged fields (recursively). You can't stackalloc string[] or arrays of structs containing references, because the GC doesn't scan stack-allocated buffers for references.

3. Stack size limits and why overflow is fatal

• Default thread stack sizes are ~1 MB on Windows and typically 8 MB for the main thread on Linux (secondary threads often ~1.5 MB in .NET); thread-pool threads use the runtime default. Deep call chains in ASP.NET Core already use some of it.
• A StackOverflowException can't be caught — the runtime terminates the process immediately (no finally, no logging). In a web app, every in-flight request on that instance fails and the container restarts.
• So never stackalloc with a size controlled by user input or unbounded data.

4. The hybrid stackalloc-or-ArrayPool pattern

const int StackThreshold = 256;   // chars

char[]? rented = null;
Span<char> buffer = length <= StackThreshold
    ? stackalloc char[StackThreshold]
    : (rented = ArrayPool<char>.Shared.Rent(length));
try
{
    buffer = buffer[..length];
    Fill(buffer);
    return Process(buffer);
}
finally
{
    if (rented is not null) ArrayPool<char>.Shared.Return(rented);
}

• Small inputs (the common case) use the stack — zero allocation.
• Large inputs use a pooled array — no stack risk, still minimal allocation.
• Use a constant size in the stackalloc (here StackThreshold) so the JIT can optimise, then slice.
• Always return pooled arrays in finally. Clear them first if they held sensitive data.

5. Why not stackalloc in loops

for (int i = 0; i < items.Count; i++)
{
    Span<byte> tmp = stackalloc byte[256];   // NOT freed per iteration!
}

Stack memory from stackalloc is released only when the method returns, not at the end of the loop body. Each iteration allocates more stack — 1,000 iterations × 256 bytes = 256 KB; a larger loop overflows the stack. Hoist the stackalloc outside the loop and reuse the buffer (analyser CA2014 warns about this).

6. SkipLocalsInit

By default, the C# compiler emits the localsinit flag, so the runtime zeroes stack-allocated memory and locals. For large stackalloc buffers that you'll fully overwrite, zeroing is wasted work. [SkipLocalsInit] (on a method, type, or module; requires <AllowUnsafeBlocks>true</AllowUnsafeBlocks>) removes the flag:

[SkipLocalsInit]
static int Encode(ReadOnlySpan<char> input, Span<byte> output) { Span<byte> scratch = stackalloc byte[512]; ... }

Risk: the buffer contains garbage from previous stack frames — reading before writing can leak data or produce nondeterministic bugs. Use only when every byte is written before being read.

7. Choosing a threshold

• Common BCL thresholds are 256–1024 bytes (e.g. 256 chars, 512 bytes, 1 KB).
• Consider: element size × count, the method's position in the call stack (deep recursion? called from deep middleware?), and the platform's stack size.
• Prefer small constant thresholds; above ~1–2 KB, the benefit vs ArrayPool diminishes while risk grows.
• Benchmark: stack vs pool for typical sizes; make sure the common case hits the stack path.

8. A production example

A service computed HMAC signatures for webhooks using stackalloc byte[payload.Length] for the encoded payload. A partner occasionally sent multi-megabyte payloads, and the process crashed with a stack overflow — no exception logs, just container restarts and failed in-flight requests. We switched to the hybrid pattern (stack for ≤ 1 KB, ArrayPool above) and computed the HMAC incrementally over streams for large payloads. Crashes stopped; small payloads stayed allocation-free.