Add a counter for gen0 budget

[davidfowl]

Background and Motivation

The gen0 budget can be used one of the signals to better understand when the GC is going to collect. It's not the only signal but it's an important one.

Proposed Feature

Today that information is readily available as an GC event but not an event counter. We can either synthesize a counter in our diagnostic tools or emit a counter from the runtime. I don't have a preference but I would like to see the data along side other counters.

[Maoni0]

I think this would be a good counter to expose and does make sense as a user facing feature as it tells you how much allocation will happen till the next GC.

[davidfowl]

@Maoni0 Sweet! I was also going to suggest something about a survived bytes gen0 and gen1 counter (since last GC) but I wasn't exactly sure if it would be as useful.

@tommcdon Should I move this to dotnet/runtime since we're going to make it a counter?

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

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

Issue Details

---

Background and Motivation

The gen0 budget can be used one of the signals to better understand when the GC is going to collect. It's not the only signal but it's an important one.

Proposed Feature

Today that information is readily available as an GC event but not an event counter. We can either synthesize a counter in our diagnostic tools or emit a counter from the runtime. I don't have a preference but I would like to see the data along side other counters.

Author:	davidfowl
Assignees:	-
Labels:	enhancement, area-Diagnostics-coreclr, untriaged
Milestone:	-

[Maoni0]

in theory, dotnet counter could enable the runtime provider + gc keyword + informational level to get the GCGlobalHeapHistory event's 'FinalYoungestDesired' field for this so it doesn't require any runtime changes.

[davidfowl]

in theory, dotnet counter could enable the runtime provider + gc keyword + informational level to get the GCGlobalHeapHistory event's 'FinalYoungestDesired' field for this so it doesn't require any runtime changes.

The only problem with that is we have to update all of the tools that show counters. APM tools, dotnet counter, visual studio, crank etc.

[Maoni0]

why? I meant dotnet counter could enable the provider on the user's behalf.

[davidfowl]

Right now counters emitted from the runtime have multiple consumers and they don't dotnet counters to consume metrics. There are different APIs:

1. In process MetricListener for metrics.
2. In process EventListener to get EventCounters.
3. Out of process via EventPipe/ETW + TraceEvent to consume counters and events.

So we need to decide how this data gets emitted from the runtime and how many pieces of consuming code need to change to get this new counter. Ideally we would reduce the amount of code consumers need to write.

[davidfowl]

Any chance of getting this into NET 8?