RuntimeInformation causes unexpected allocations

[timcassell]

Description

While debugging and attempting to fix flaky allocation measurements in BenchmarkDotNet (dotnet/BenchmarkDotNet#2562), I found that System.Runtime.InteropServices.RuntimeInformation causes allocations during a GC.Collect().

I only observe this behavior in net8.0 runtime. net48 runtime using Microsoft.DotNet.PlatformAbstractions nuget package does not reproduce (or AppDomain.MonitoringTotalAllocatedMemorySize just doesn't observe it, since GC.GetTotalAllocatedBytes is not available in net48).

Reproduction Steps

Create a Console application and run this code in Release with net8.0.

public static void Main()
{
    var bench = new Bench();
    var action = bench.Benchmark1;
    Warmup(action);

    // Switch these lines to observe 0 allocated bytes.
    var frameworkDescription = RuntimeInformation.FrameworkDescription;
    //var frameworkDescription = "";

    var initial = GetAllocatedBytes();
    action();
    var final = GetAllocatedBytes();

    Console.WriteLine($"allocated bytes: {final - initial}");

    GC.KeepAlive(frameworkDescription);
}

static long GetAllocatedBytes()
{
    GC.Collect(); // We only observe allocated bytes when GC.Collect() is called.
    return GC.GetTotalAllocatedBytes(precise: true);
}

static void Warmup(Action action)
{
    for (int i = 0; i < 100; i++)
    {
        action();
    }
}

public class Bench
{
    public void Benchmark1() => TestMethod();
    
    [MethodImpl(MethodImplOptions.NoInlining)]
    public static ulong TestMethod()
    {
        var r = 1ul;
        for (var i = 0; i < 50_000_000; i++)
        {
            r /= 1;
        }
        return r;
    }
}

Expected behavior

Console prints allocated bytes: 0.

Actual behavior

Console prints allocated bytes: 336 (sometimes it prints 48 or 672).

Regression?

No response

Known Workarounds

No response

Configuration

Windows 10 x64
.Net 8.0

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[jkotas]

There are number of background threads running in your app: finalizer thread, tiered JIT thread, diagnostics (event pipe) thread, ... . All these threads can wake up, do work and allocate as side-effect. The allocations you are seeing are likely from these background threads waking up and allocating.

When I run your repro under debugger (that also affects the timing), I see some allocations from finalizers running on the finalizer thread while your benchmark is running in the foreground.

Adding/removing RuntimeInformation.FrameworkDescription call is changing the timing and the work that some of these background threads need to do. For example, adding the call can introduce more work for the tiered JIT thread.

[timcassell]

@jkotas Sure, I can believe that we may get some random allocations from background threads we cannot control, but I don't believe that's what's happening here. If I measure it repeatedly, I see the same results repeatedly.

public static void Main()
{
    var bench = new Bench();
    var action = bench.Benchmark1;
    Warmup(action);

    // Switch these lines to observe 0 allocated bytes.
    var frameworkDescription = RuntimeInformation.FrameworkDescription;
    //var frameworkDescription = "";

    Console.WriteLine($"allocated bytes: {MeasureAllocations(action)}");
    Console.WriteLine($"allocated bytes: {MeasureAllocations(action)}");
    Console.WriteLine($"allocated bytes: {MeasureAllocations(action)}");
    Console.WriteLine($"allocated bytes: {MeasureAllocations(action)}");
    Console.WriteLine($"allocated bytes: {MeasureAllocations(action)}");
    Console.WriteLine($"allocated bytes: {MeasureAllocations(action)}");
    Console.WriteLine($"allocated bytes: {MeasureAllocations(action)}");
    Console.WriteLine($"allocated bytes: {MeasureAllocations(action)}");
    Console.WriteLine($"allocated bytes: {MeasureAllocations(action)}");
    Console.WriteLine($"allocated bytes: {MeasureAllocations(action)}");

    GC.KeepAlive(frameworkDescription);
}

static long MeasureAllocations(Action action)
{
    var initial = GetAllocatedBytes();
    action();
    var final = GetAllocatedBytes();
    return final - initial;
}

allocated bytes: 336
allocated bytes: 336
allocated bytes: 336
allocated bytes: 336
allocated bytes: 336
allocated bytes: 336
allocated bytes: 336
allocated bytes: 336
allocated bytes: 336
allocated bytes: 336

Without GC.Collect():

allocated bytes: 0
allocated bytes: 0
allocated bytes: 0
allocated bytes: 0
allocated bytes: 0
allocated bytes: 0
allocated bytes: 0
allocated bytes: 0
allocated bytes: 0
allocated bytes: 0

[jkotas]

GC.Collect() triggers Gen2 GC. Gen2 GC triggers ArrayPool cleanup on finalizer thread. ArrayPool cleanup allocates ConditionalWeakTable enumerator at this callstack:

 # Child-SP          RetAddr               Call Site
00 000000ad`7007f178 00007ff7`d81d5630     coreclr!JIT_New [D:\a\_work\1\s\src\coreclr\vm\jithelpers.cpp @ 2435] 
01 000000ad`7007f180 00007ff7`d81d4c92     System_Private_CoreLib!System.Runtime.CompilerServices.ConditionalWeakTable`2[[System.__Canon, System.Private.CoreLib],[System.__Canon, System.Private.CoreLib]].System.Collections.Generic.IEnumerable<System.Collections.Generic.KeyValuePair<TKey,TValue>>.GetEnumerator()+0xfffffff7`da3d20f0
02 000000ad`7007f1e0 00007ff7`d81d49a9     System_Private_CoreLib!System.Buffers.SharedArrayPool`1[[System.Char, System.Private.CoreLib]].Trim()+0xfffffff7`da4fd382
03 000000ad`7007f2e0 00007ff8`37d4b846     System_Private_CoreLib!System.Gen2GcCallback.Finalize()+0xfffffff7`da6fc319
04 000000ad`7007f330 00007ff8`37c0e3cd     coreclr!FastCallFinalizeWorker+0x6 [D:\a\_work\1\s\src\coreclr\vm\amd64\CallDescrWorkerAMD64.asm @ 26] 

[jkotas]

(It is not the only alllocation that ArrayPool cleanup does.)

[timcassell]

Hm, that makes sense. Can the allocations be eliminated? Or do you have any suggestions to avoid the issue?

[jkotas]

I suppose it may be possible to eliminate it by somehow, but I am sure whether it is worth the troubles.

Many of the background runtime activities can allocate for number of different reasons. It does not make sense to try to eliminate every single one of them to make the benchmark.net alllocation analyzer reliable.

If you do not want the background activities to interfere, the best way is to disable them: disable tiered JIT, disable event source, hang the finalizer by creating a finalizer with infinite sleep, etc.

[cshung]

If you are okay with the overhead, The native ICorProfiler allows you to capture all allocations.

You can filter out allocation that does not happen on the thread of interest. We have a sample test case here to show how it could be done.

https://github.com/dotnet/runtime/blob/main/src/tests/profiler/native/gcallocateprofiler/gcallocateprofiler.cpp

[timcassell]

I don't know what other allocations there are, but I suppose a low effort reduction there would be to use a struct enumerator for the ConditionalWeakTable (internal only for safety, of course).

If you do not want the background activities to interfere, the best way is to disable them: disable tiered JIT, disable event source, hang the finalizer by creating a finalizer with infinite sleep, etc.

Hanging the finalizer thread is certainly an interesting idea. I'll try to see if I can work that into our tests.

[dotnet-policy-service]

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