[Proposal] Add GC.GetAllocatedBytesForCurrentThread in .Net Standard vNext #771
Description
Given the recent focus on reducing allocations in .Net (e.g. the introduction of Span<>). I think it would be useful to have a simple tool for tracking allocations on the current thread. I would categorise this similarly to the Stopwatch class; yes I could use an external profiler, but having an in process solution is so much more flexible. I want to use something like this for monitoring, unit tests and even sanity-checking refactorings.
The good news is that GetAllocatedBytesForCurrentThread was added to .Net Core CLR a while back now (see dotnet/corefx#10157, dotnet/coreclr#6953 and dotnet/corefx#12489 ), and it offers a robust model to follow.
The bad news is that the other runtime GC's don't currently have similar implementations and given GC differences the code probably can't be ported straight over.
I understand that there is a higher cost implied by adding API's to the Standard that don't currently have obvious implementations for each runtime, but I do think this is an area where there will be growing interest in such an API. For example on Mono where allocations are critical to the performance of games and mobile apps.
Furthermore there are already some people in the wild attempting cross runtime solutions, but it is a lot of hoops even when .Net Core is in play. See for example what Benchmark.Net is having to do right now: Benchmark.Net/GCStats.cs). Adding GetAllocatedBytesForCurrentThread to the standard would ease this immediate issue and give the opportunity for the other runtimes to add valuable diagnostic information in the future (with PlatformNotSupportedExceptions perhaps being the cost in the interim).