CS4007 - Async Span Prevents Dangling Pointer

Every millisecond your web API spends allocating strings and arrays is a millisecond the garbage collector has to eventually clean up. At scale — thousands of requests per second — that tax compounds into measurable latency spikes and GC pauses that ruin your P99 numbers. The .NET team didn't add Span<T> and Memory<T> as academic exercises; they built them because the runtime itself needed a way to parse HTTP headers, JSON, and binary protocols without spraying the heap with short-lived allocations.

Before these types existed, the only way to work with a 'slice' of an array or a substring was to call Array.Copy or String.Substring — both of which allocate brand-new objects. If you were parsing a 10 KB HTTP request and needed 40 substrings, you'd create 40 heap objects just to read data you already had. Span<T> and Memory<T> solve this by letting you create a lightweight view over existing memory — whether that memory lives on the stack, the heap, or even unmanaged native memory — with no allocation at all.

By the end of this article you'll understand the internal representation of both types, know exactly when each one is appropriate, be able to write genuinely zero-allocation parsers, and understand the safety rules that make the compiler and runtime enforce correctness. You'll also walk away knowing the three most common production mistakes teams make when they first adopt these types.

How Span Works Under the Hood — Stack-Only Views Into Any Memory

Span<T> is a ref struct — that single fact drives every constraint you'll encounter. A ref struct can only live on the stack. It can never be boxed, stored in a field of a regular class, used as a generic type argument, or captured by a lambda. The compiler enforces all of this at compile time, so you get a hard error rather than a runtime surprise.

Internally, Span<T> is just two fields: a managed pointer (ref T) to the first element, and an integer length. On 64-bit systems that's 16 bytes total. There's no array object, no string object, no allocation. When you call someSpan[3], the JIT generates a single bounds-checked pointer dereference — essentially the same code you'd get from a raw unsafe pointer, but with the safety guarantee that the index is validated.

The key insight is that Span<T> can point at three completely different memory regions without changing its API: a managed array on the heap, a stackalloc block on the stack, or a block of unmanaged memory obtained from Marshal.AllocHGlobal. Your parsing code doesn't care which one — it just reads and writes through the Span interface identically. This is what makes Span<T> the universal buffer abstraction in modern .NET.

Memory and ReadOnlyMemory — When You Need to Cross Async Boundaries

Span<T> is perfect for synchronous, stack-contained operations. But the moment you hit an await, the current stack frame evaporates and resumes on a potentially different thread. A ref struct can't survive that transition, so Span<T> simply can't cross an await boundary. This is where Memory<T> comes in.

Memory<T> is a regular struct — not a ref struct — so it can be stored in class fields, used in async methods, returned from lambdas, and put in collections. It wraps the same concept (a segment of contiguous memory with an offset and length) but does so through a level of indirection: it holds a reference to the owner object (array, MemoryManager<T>, or string), plus an index and length. When you actually want to process the data, you call .Span on it to get a Span<T> at that point — that's where the 'read through a stack-safe view' pattern kicks in.

The key production pattern is: accept Memory<T> in your async method signatures, pass Span<T> into your synchronous helper methods that do the actual parsing or computation. This keeps allocations zero while remaining async-friendly. IMemoryOwner<T> and MemoryPool<T> extend this further by giving you a rented, lifetime-managed buffer — critical for socket and pipe-based I/O where you need pooled buffers that survive multiple await points.

Building a Real Zero-Allocation CSV Parser — Putting It All Together

Theory only sticks when you build something real. Let's write a CSV line parser that processes an entire row without a single heap allocation except the final result array. This is the kind of code you'd find inside a high-throughput data ingestion pipeline or a game server parsing player commands at 60 fps.

The core technique is iterating over a ReadOnlySpan<char> by repeatedly finding delimiters and slicing — no Split(), no Substring(), no List<string> intermediate collection. We use a fixed-size Span<Range> to record where each field starts and ends, then we materialize strings only at the very end when the caller actually needs them.

This pattern mirrors exactly how System.Text.Json and ASP.NET Core's routing engine work internally. Understanding it means you can read — and contribute to — performance-critical library code with confidence.

Performance Benchmarks, Gotchas, and Production Rules

Knowing the API is one thing. Knowing when you've actually eliminated allocation — and when you've accidentally added it back — is what separates production-ready code from aspirational code. BenchmarkDotNet is your ground truth here; gut feelings about allocations are reliably wrong.

The most dangerous false economy is calling .ToString() or creating a new string inside a hot path you thought was allocation-free. One ToString() call on a ReadOnlySpan<char> inside a loop that runs a million times creates a million strings. Profile first with dotnet-trace or PerfView; optimize second.

Another production reality: Span<T> slicing is O(1) — it's literally adding an integer to a pointer. But accessing elements through a Span in a tight loop is only as fast as unsafe pointer access when the JIT eliminates bounds checks. The JIT does eliminate bounds checks when it can prove the index is within range (e.g. iterating with a for loop up to .Length). If you're using arbitrary computed indices, you may not get that optimization. When it matters, benchmark both the Span version and the unsafe version and let the numbers decide.

Choosing Between Span and Memory — Decision Tree for Real Code

Newcomers often ask: "Should I use Span<T> or Memory<T> in my API?" The answer depends entirely on the lifetime of the slice and where the data will be processed. This decision tree will help you pick the right type the first time, avoiding the compile-time error or unnecessary indirection.

Start with two questions: 1) Does this slice need to live past an await? 2) Will this value be stored in a field, collection, or captured by a lambda? If yes to either, use Memory<T>. If the slice is purely used synchronously within a single method scope, use Span<T>.

For public APIs that accept data to be processed asynchronously (e.g., a method that queues work to a background thread), always use Memory<T>. The caller can convert from a Span to Memory only if the underlying memory is heap-based (array or string). That conversion is a cheap O(1) operation. But if you force a caller to provide Span<T> and they need async processing, they're stuck. Design for the async case by default.

Frequently Asked Questions