GC.GetAllocatedBytesForCurrentThread always returns 0 when processor affinity is set to single proc

[adamsitnik]

When the processor affinity is set in explicit way GC.GetAllocatedBytesForCurrentThread always returns 0. Even is something was allocated.

using System;

namespace gcstats
{
    class Program
    {
        static void Main(string[] args)
        {
            var before = System.GC.GetAllocatedBytesForCurrentThread();
            Console.WriteLine("Hello World!");
            var after = System.GC.GetAllocatedBytesForCurrentThread();
            Console.WriteLine($"after - before = {after - before}");
            Console.ReadLine();
        }
    }
}

start /affinity 1 dotnet.exe run
Hello World!
after - before = 0

start dotnet.exe run
Hello World!
after - before = 7552

dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.1.300-rc1-008673
 Commit:    f5e3ddbe73

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.300-rc1-008673\

Host (useful for support):
  Version: 2.1.0-rc1
  Commit:  eb9bc92051

@jkotas @Maoni0 is this expected behavior? am I doing something wrong?

I am porting CoreCLR benchmarks from xunit-performance to BenchmarkDotNet and I have faced this issue today when I was comparing the results of some unstable benchmarks with affinity set and without.

/cc @jorive

[jkotas]

Yes, this is how the API was implemented. Setting affinity to single proc will disable allocation contexts, that in turn makes this API to always return 0.

I have pointed this non-intuitive behavior when this API was introduced: dotnet/coreclr#6953 (comment). I agree that the current behavior does not sound right:

[adamsitnik]

@jkotas once again big thanks for help!

I am going to close this issue and open a new one with a list of requirements that we have once I finish porting all repositories and the requirements are crystal clear.

[jkotas]

I think we should keep this issue opened. It is a bug that we should look into fixing.

[VSadov]

Compared to other issues, this is not a ship-stopper for 3.0
At this point this should be Future.

[mangod9]

moving to 7

[MikeStall]

Fyi - this appears to affect all Azure Websites.