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?

[dotnet-issue-labeler]

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.

[ghost]

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?

[tommcdon]

@cshung would you be interested in taking a look?

[noahfalk]

@davidfowl - I can't speak to what the GC team might already have on their plate, but do you care about this request enough in .NET 8 to get the Platform complete deadline waived?

[davidfowl]

If assuming it is trivial to add yes. If you told me we had to design a brand new set of APIs then I would say no. I would like to get this added in the next LTS (.NET 8) 😄.

This information is important, and it is buried today, none of the tools show it.

[tommcdon]

If assuming it is trivial to add yes. If you told me we had to design a brand new set of APIs then I would say no. I would like to get this added in the next LTS (.NET 8) 😄.

@cshung is this something that is easy to implement for .NET 8 or will it require new API's.

[cshung]

It is not too hard to implement, but it will need a new API.

I plan to address this (and the heap size one) after I have done some more diagnostics work related to dynamic GC. I definitely see the value in this and would love to have the counters. At the point, I am more worried that I may not be able to make it before the fork.

We probably need a bit more design here as well. Do we just want gen 0 or other generations as well? The budgets are per heap, do we expose them all? I don't think we can expose multiple numbers in a metric, or have a variable number of metrics, how about some aggregates (average or max?)

Also, do we want to have the value GC decided to give out, or the consumed one at the moment? Think of that this way, by the end of that last GC, GC decides that each heap can allocate 10 more megs before the next gen0 GC happens. You have allocated about 4 meg right now, should it report 10, or should it report 6?

From an implementation perspective, there are a couple of issues that will be in our way.

• As of now, RuntimeEventSource can't access the GC values, we will need an (at least internal) API to send them over.
• If we want the consumed budget value, since all threads are concurrently allocating, we probably need to have some synchronization or accept that the number could be off. Otherwise, we can simply cache the value when the GC makes the decision and report it as is.
• If we want the API to return the individual heap budget values, that will be a variable number of numbers to return from native. Variable-sized return value through the boundary has always been tricky. If we aggregative within the API than things get easier (just a fixed number of numbers to return)

Beyond these, I expect the API should not be too hard to implement.

[davidfowl]

cc @reyang