Object Stack Allocations behavior / limits

[ladeak]

Given the following code on .NET 10 RC1, Win11 x64:

using System.Diagnostics;
using System.Runtime.CompilerServices;

var t = new Test();
t.Measurement();

public class Test
{
    public void Measurement()
    {
        long sum = 0;
        long beginning = GC.GetTotalAllocatedBytes(true);
        for (int i = 0; i < 100; i++)
            sum += DoWork();

        var allocated = GC.GetTotalAllocatedBytes(true) - beginning;
        Console.WriteLine($"Allocated: {allocated}, Sum: {sum}");
    }

    [MethodImpl(MethodImplOptions.AggressiveOptimization)]
    public long DoWork()
    {
        var obj0 = new MyClass();
        return obj0.Get();
    }
}

public class MyClass
{
    private long _a00 = (Stopwatch.GetTimestamp() / 1);
    private long _a01 = (Stopwatch.GetTimestamp() / 1);
    private long _a02 = (Stopwatch.GetTimestamp() / 1);
    private long _a03 = (Stopwatch.GetTimestamp() / 1);
    private long _a04 = (Stopwatch.GetTimestamp() / 1);
    private long _a05 = (Stopwatch.GetTimestamp() / 1);
    private long _a06 = (Stopwatch.GetTimestamp() / 1);
    private long _a07 = (Stopwatch.GetTimestamp() / 1);
    private long _a08 = (Stopwatch.GetTimestamp() / 1);
    private long _a09 = (Stopwatch.GetTimestamp() / 1);
    private long _a10 = (Stopwatch.GetTimestamp() / 1);
    private long _a11 = (Stopwatch.GetTimestamp() / 1);
    private long _a12 = (Stopwatch.GetTimestamp() / 1);
    private long _a13 = (Stopwatch.GetTimestamp() / 1);
    private long _a14 = (Stopwatch.GetTimestamp() / 1);
    private long _a15 = (Stopwatch.GetTimestamp() / 1);
    private long _a16 = (Stopwatch.GetTimestamp() / 1);

    public long Get() => Stopwatch.GetTimestamp()
        + _a00 + _a01 + _a02 + _a03 + _a04 + _a05 + _a06 + _a07 + _a08 + _a09
        + _a10 + _a11 + _a12 + _a13 + _a14 + _a15 + _a16;
}

Prints on my machine: Allocated: 0, Sum: 7139329661393982

When I remove the / 1 or replace it with * 1 at the initialization of the fields on MyClass, (private long _aXX = (Stopwatch.GetTimestamp()); it prints:

Allocated: 15200, Sum: 7140731878244270 which indicates it could not stack allocate MyClass instance.

What drives this behavior?

[huoyaoyuan]

The measurement is not precise. 100 loop is too few and the class is never stack allocated.

Increasing loop count to 100000, both approaches are allocating:

/ 1: Beginning: 658520 Allocated: 13680152, Sum: 818384063185004657
No-op: Beginning: 658520 Allocated: 15200000, Sum: 818764459825930282
* 1: Beginning: 658520 Allocated: 15200000, Sum: 820184664027250155

[ladeak]

In your measurements:

1. Why the Allocated for / 1 case is not equal to the 'no-op' and * 1 cases?
2. Why / 1 allocates when the loop is larger but not when it is smaller?

I think when the loop count is increased, then Measurement() method gets optimized, DoWork() method gets inlined and MyClass becomes heap allocated during this.
I think this, because when I apply [MethodImpl(MethodImplOptions.AggressiveOptimization)] on Measurement() method I can observe the same behavior with a loop count of 100 (meaning allocation for / 1 case).

This makes me think that the loop count does not make the measurement imprecise.

[hez2010]

If the constructor of MyClass or obj0.Get() is not inlined into the callsite, you will end up obj0 getting heap allocated.
The inliner is driven by some heuristics that evaluate the benefit/cost to determine whether to inline a method.
For example, when a method becomes too large the compiler may choose to reject the inlining, but if it has some foldable expressions, the condition may be loosened by a bit.
In this case, you may want to add a parameterless constructor to your MyClass and put a [MethodImpl(MethodImplOptions.AggressiveInlining)] on both the constructor and Get.

[ladeak]

Thank you for the suggestion, I will try that. Although when the /1 is removed, the code should get smaller, no?

[huoyaoyuan]

Although when the /1 is removed, the code should get smaller, no?

* 1 is optimized away by the C# compiler while / 1 is not. It's left in the IL and affects the inliner's heuristic.

[ladeak]

So it is just the ctor inline-ing and corresponding heuristics? Although heuristics seems a bit odd in this case optimizing one case but not others that are seemingly opposite what I would normally expect.

[hez2010]

Your constructor is already too large to get inlined. It's just that you added a / 1 to make the JIT think your method can be somewhat "foldable" so that the JIT increases the inline heuristics multiplier (which is used to compute the benefit/cost) by a bit for you. And it happens to make your constructor able to be inlined under the new multiplier value because now the JIT thinks it's more beneficial to inline your constructor.
The heuristics change almost every version of .NET so don't rely on the behavior of heuristics.