Runtime: Add diagnostic tracker API

[terrajobst]

As discussed in issue dotnet/runtime#17891, we would like a higher-level tracking API for measuring allocations. The goal is to make an API that is similar to Stopwatch:

C# namespace System.Diagnostics { public class ManagedAllocationTracker { public static ManagedAllocationTracker StartNew(); public long AllocatedBytes { get; } } }

This API will also allow tracking bytes across execution contexts.

@KrzysztofCwalina suggested to make it even more general purpose and allow the tracker to track more diagnostic information.

[benaadams]

Also public long AllocatedObjects { get; }?

[Maoni0]

@benaadams, can you please give a scenario where you make use of # of allocated objects?

[vancem]

The reason behind Maoni's question is that unlike the byte pointer (which we track because it is needed for the implementation, an object counter is not, and thus is 'pure overhead'. It is not large, but anything done on every allocation (by default), is overhead we really don't want.

We are likely to want to leave it out for that reason...

[benaadams]

It gives more character to the allocations; so if I did:

var tracker = ManagedAllocationTracker.StartNew();

streamIn.CopyTo(streamOut);

tracker.Stop(); // Maybe, similar to Stopwatch?

It would tell me 82kB which I might think is crazy high; however the objects allocated would be 1 which would provide context.

There is always memory tracing for investigation, which is fully featured in .NET, so if it came at an extra overhead I don't think it would be worth it.

However, the other stopwatch methods could be useful e.g.
Reset(), Restart(), Start(), Stop()

This could easily be handled in the external code, but it would be less messy if it could be internalized into the tracer instance.

[mattwarren]

Out of interest, will this API be added to Desktop CLR as well or is it intended for CoreCLR only?

@KrzysztofCwalina suggested to make it even more general purpose and allow the tracker to track more diagnostic information.

What additional diagnostic information could it track?

[mattwarren]

Also, will the API be fine-grained enough to support code like this, i.e. get the size of a single object?

var tracker = ManagedAllocationTracker.StartNew();
var text = "Some Text";
// will tracker.AllocatedBytes now be the exact size of the string "Some Text"?
var textSize = tracker.AllocatedBytes;

[MendelMonteiro]

This would be extremely handy for us in unit testing code which we try to make allocation free. Currently we monitor the GC count before and after but the number of iterations needed to guarantee that it is allocation free is completely arbitrary and increases the test time.

In our use case it is fairly binary, AllocatedBytes > 0 == bad, and so the number of allocated objects is irrelevant.

[khellang]

How do you stop it? :trolleybus:

[vancem]

The class should have a Stop() method (analogous to Stopwatch), but it will also stop when the object dies. It should also probably have the other analogous methods like Reset() and Start() and Restart() and IsRunning().

[khellang]

I've always liked using blocks for these things. They make it pretty clear whre the allocations are measured.

[vancem]

Supporting IDisposable is also very reasonable.

[karelz]

We need formal API proposal.

[stephentoub]

@terrajobst, given that we have https://github.com/dotnet/corefx/issues/10157, and given https://github.com/dotnet/corefx/issues/30644 and https://github.com/dotnet/corefx/issues/34631, is this still something we're pursuing, or can this issue be closed?

[tommcdon]

It seems like this issue was addressed and has no activity for over a year, so closing