[Proposal] Prioritize "Scalar Replacement of Aggregates" (SROA) to achieve true Zero-Cost Abstractions

[Mortezamir81]

Description

I have been following the progress on Object Stack Allocation (Issue #11192 and the current roadmap in #104936). While enabling stack allocation for classes is a massive step forward, I would like to propose prioritizing Scalar Replacement of Aggregates (SROA) as the ultimate goal for small, non-escaping reference types.

The Distinction

Currently, the focus seems to be on allocating the object on the stack (preserving the object header, method table pointer, etc.).
While this reduces GC pressure, it still incurs:

1. Header Overhead: Space taken by the object header/method table.
2. Indirection: Accessing fields might still involve pointer arithmetic relative to the stack frame.

Scalar Replacement (SROA) goes further by "exploding" the object into its constituent fields (locals/registers) and eliminating the object identity entirely.

Why Prioritize SROA?

If the JIT can perform Scalar Replacement for reference types (similar to how it handles structs):

1. True Zero-Cost: It removes the overhead of the Object Header. A class with two int fields becomes exactly equal to two int local variables.
2. Register Allocation: "Exploded" fields are easier for the register allocator to handle compared to fields residing in a stack-allocated memory block.
3. Modern Idioms: It perfectly complements modern "fluent" APIs and wrapper types (e.g., Option<T>, Result<T>, or Builder patterns) where developers prefer classes for API ergonomics but pay a performance penalty.

Proposal

I suggest that SROA should not just be an "Advanced/Future" optimization (as hinted in #104936 under "Advanced"), but a core pillar of the .NET 11 performance roadmap.

Achieving parity between struct and class for local-scoped data would fundamentally change how we write high-performance C#, removing the need to manually refactor small classes into structs or ref structs solely for optimization.

Related Issues:
Refers to roadmap: #104936

[MihuBot]

I'm a bot. Here are possible related and/or duplicate issues (I may be wrong):

• CLR/JIT should optimize "alloc temporary small object" to "alloc on stack" automatically #4584
• JIT: Support object stack allocation #11192

[jakobbotsch]

The JIT already implements scalar replacement of aggregates. It is called promotion in JIT parlance.
We are also able to promote stack allocated objects today, though there are cases where it does not kick in, and there are several improvements we want to make (to promotion itself and also to its interaction with object stack allocation).

@AndyAyersMS may have more notes on the intersection of object stack allocation and promotion.

[huoyaoyuan]

Such optimization is already working for trivial cases:

struct A
{
    public int X, Y;
}

class B
{
    public int X, Y;
}

static int M1(int X, int Y)
{
    var a = new A { X = X, Y = Y };
    return a.X + a.Y;
}

static int M2(int X, int Y)
{
    var b = new B { X = X, Y = Y };
    return b.X + b.Y;
}

Both cases are optimized into a single lea eax, [rcx+rdx].

[AndyAyersMS]

prioritizing Scalar Replacement of Aggregates (SROA) as the ultimate goal for small, non-escaping reference types.

Yes, that is the goal.

Generally, if the JIT can stack allocate it can also promote. As work has proceeded on stack allocation we have also made various enhancements to local morph (which determines address exposure and so gates promotion) to try and ensure the fields get promoted.

There are some notable exceptions, eg stack allocated arrays, where it seems unlikely that SROA will ever be viable, but we still think stack allocation is worthwhile.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[AndyAyersMS]

@Mortezamir81 if you have specific examples you know of that would be helpful...