Why can’t ref structs be boxed?

[colejohnson66]

Spans are an amazing feature, but they have a limitation that they can’t exist on the heap. Instead, one must use Memory<T>, but Memory<T>.Span has quite a bit of overhead, and, if used in an async context, may need to be extracted multiple times.

What’s the reasoning behind this limitation? The GC obviously had to be augmented to handle interior pointers on the stack, so why was that logic not extended to scanning the heap?

[En3Tho]

Basically, lifetime safety issues. You can have stack to heap references but not vice versa because it is really easy to shoot yourself in a foot (e.g. stack can be already used for something else or discarded). Depending on your use case you can go unsafe and use pointers to pass ref structs around but you're in your own then.

Another possible thing is that arbitrary heap to heap references might be costly for gc to scan/walk but I'm not sure how much it is.

[gfoidl]

What’s the reasoning behind this limitation?

Thread safety. And by the stack-only nature, they are by construction thread-safe, so no other measure therefore need to be taken, and hence that's a net win for perf.

Span is larger than the machine's word size, so reading / writing a span is not atomic.
If they are allowed to live on the heap, then caution for torn reads / writes must be taken into account.

Stack memory is per thread, so by definition only the associated thread can access that memory (in a safe context). The problem with torn reads / writes doesn't exist here.

[behdad088]

Hi @colejohnson66

You know how Span is super fast and efficient because it lets you work with slices of memory without having to make extra copies? The trick to making it fast is that it always lives on the stack, not the heap. The stack is a smaller part of memory that’s quick to access but temporary—it's where things like local variables in a method live. Once the method finishes, anything on the stack is wiped out.

Now, the heap is where stuff that sticks around longer lives (like objects you create with new). But if Span (or any ref struct) were allowed to be placed on the heap, it would break. Why? Because Span often holds references (or "pointers") to stack memory. If the stack memory disappears (when the method finishes), and you have something pointing to that memory from the heap, you’d be left with a dangling pointer—basically a reference to garbage data that could crash the program.

To avoid that mess, C# says: "Nope, no ref struct on the heap." This keeps everything safe and ensures that Span stays fast without any complicated memory tracking.

The garbage collector (GC), which cleans up stuff on the heap, isn’t designed to handle these tricky pointers from the heap to the stack. Modifying the GC to do that would slow everything down and add a ton of complexity. So instead, C# just keeps ref struct types limited to the stack.

If you need something similar that can live on the heap (like when you're working with async methods), you have to use Memory, which is kind of like Span but can be heap-allocated. The trade-off is that Memory is a bit slower since it allows heap allocation, but it gets the job done in more flexible situations, like when working asynchronously.

So, basically, it's all about balancing speed, safety, and not breaking the system by letting Span point to memory that might disappear!

[AustinWise]

This is a similar discussion on the CSharp language board. To answer your question:

The GC obviously had to be augmented to handle interior pointers on the stack, so why was that logic not extended to scanning the heap?

That discussion quotes this article:

These references are called interior pointers, and tracking them is a relatively expensive operation for the .NET runtime’s garbage collector. As such, the runtime constrains these refs to only live on the stack, as it provides an implicit low limit on the number of interior pointers that might be in existence.

So it's a performance optimization.

I don't know much about the CLR GC, but I went looking for what might cause it to be expensive. It appears that the VM side of CoreCLR passes GC_CALL_INTERIOR to the GC to let it know a reference might be an interior pointer. When the GC sees that flag, like here in GCHeap::Promote, it has to to call find_object to find the beginning of the object. It needs to find the beginning so it can set the mark bit in the header to indicate the object is reachable. If you step through the call to find_object, you will see that it identifies the segment an object is in and walks through the objects in the segment until it find the beginning of the object.

[tagcode]

Others already answered the question in opening.

However, Span is a mere pointer + length, and passing such to heap and to other threads is completely normal in other languages. It can be done unsafely in C# too as long as you understand that the Span cannot be used after the underlying resource is released.

The following example allocates memory from stack and passes the pointer to other threads to process.

using System.Runtime.CompilerServices;

// Number of elements and tasks
int length = 1024;
// Allocate from stack
Span<long> buf = stackalloc long[length];
// Local variable for closure
SpanUnsafe<long> @unsafe = buf;

// Concurrent work
Parallel.For(0, length, (int threadId) => {
    Span<long> _buf = @unsafe;
    _buf[threadId] = 1;
});

// Print results
for (int i = 0; i < length; i++)
    Console.WriteLine($"buf[{i}] = {buf[i]}");
// Done
Console.WriteLine();

public unsafe struct SpanUnsafe<T>
{
    nint ptr;
    public readonly int Length;

    public ref T this[int index]
    {
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        get {
            if ((uint)index >= (uint)Length) throw new IndexOutOfRangeException();
            return ref Unsafe.AsRef<T>((void*)(ptr + index * sizeof(T)));
        }
    }

    public SpanUnsafe(nint ptr, int length)
    {
        this.ptr = ptr;
        this.Length = length;
    }

    public static implicit operator Span<T>(SpanUnsafe<T> unmanagedSpan) => new Span<T>((void*)unmanagedSpan.ptr, unmanagedSpan.Length);
    public static implicit operator SpanUnsafe<T>(Span<T> span) => new SpanUnsafe<T>((nint)Unsafe.AsPointer<T>(ref span.GetPinnableReference()), span.Length);
}

[tagcode]

If you truly want to pass a Span pointing to stack to a different thread, you can just pass the unsafe pointer + length and then materialize it to Span via Span's constructor

??? But that is exactly what I am doing. First, passing unsafe pointer + length. SpanUnsafe is aggregate of those two. Second, in the other thread I'm calling Span's constructor.

The reflection emit is for compiling the three opcodes into a functions that read pointer and length from Spans since they are not public. Pointer was public after all.

which is no doubt a bad idea

In the example, Parallel uses barrier wait. The stack will not close until threads are done. The example is fine. It is fine as long as the underlying resource is not released. I'd like to hear any valid counter points.

[tagcode]

Here is an example without pointer to stack.

// Number of elements and tasks
int length = 1024;
// Allocate 
nint ptr = Marshal.AllocHGlobal(length * sizeof(long));

try {
    // Local variable for closure
    SpanUnsafe<long> @unsafe = new(ptr, length * sizeof(long));

    // Concurrent work
    Parallel.For(0, length, (int threadId) => {
        Span<long> _buf = @unsafe;
        _buf[threadId] = 1;
    });

    //
    Span<long> buf = @unsafe;
    // Print results
    for (int i = 0; i < length; i++)
        Console.WriteLine($"buf[{i}] = {buf[i]}");
} finally
{
    // Done
    Marshal.FreeHGlobal(ptr);
    Console.WriteLine();
}

[SirCxyrtyx]

You can write your Span -> SpanUnsafe operator much more simply, with no reflection:

public static implicit operator SpanUnsafe<T>(Span<T> span) => new SpanUnsafe<T>(Unsafe.AsPointer(ref span.GetPinnableReference()), span.Length);

[EgorBo]

The reflection emit is for compiling the three opcodes into a functions that read pointer and length from Spans since they are not public.

https://learn.microsoft.com/en-us/dotnet/api/system.span-1.-ctor?view=net-8.0#system-span-1-ctor(system-void*-system-int32) this Span<T>(Void*, Int32) constructor is public, you don't need the one accepting byref managed pointer here.

[tagcode]

You can write your Span -> SpanUnsafe operator much more simply, with no reflection: span.GetPinnableReference()

Yeah that one too. After sleeping, the very first though in my mind was that, hold on, wasn't Span indexer 'ref T'?