Implement generational aware analysis GC events

[LakshanF]

The events GenAwareBegin and GenAwareEnd help with analyzing GC generation issues.

CoreCLR has an implementation and NativeAOT is empty
.
Below are some notes from @cshung related to the implementation,

From an implementation perspective, here is what happens under the hood:

1. During process startup, a few configuration variables are read. If the configuration implies we need to collect a trace, we will start an event pipe section, but pause it so that no events are written to that section.
2. During GC, after the mark phase complete, we have some data that we wouldn’t have otherwise. For example, we know exactly how many bytes worth of objects are currently alive in the current generation. (In the GC speaks, we call these promoted bytes, because they are the bytes that get promoted to the next generation).
3. Using that data, comparing with the configuration, we can detect if we are currently hitting the interesting scenario (e.g. the ephemeral leaking scenario in the blog), and so we trigger the data collection process in a blocking manner so that the heap won’t change.
4. The data collection process could be either walking the heap and report the objects as traces through event pipe, or taking a heap dump, or both.
5. In case we want the trace in step 4, we will first emit the GenAwareBegin event, then walk the heap, then emit the GenAwareEnd event, these events together delineate where the heap walk begins and ends.
6. With those events, PerfView can detect the trace contains a GenAware heap collection, and it will be able to produce an analysis as the blog post shows.

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The events GenAwareBegin and GenAwareEnd help with analyzing GC generation issues.

CoreCLR has an implementation and NativeAOT is empty
.
Below are some notes from @cshung related to the implementation,

From an implementation perspective, here is what happens under the hood:

1. During process startup, a few configuration variables are read. If the configuration implies we need to collect a trace, we will start an event pipe section, but pause it so that no events are written to that section.
2. During GC, after the mark phase complete, we have some data that we wouldn’t have otherwise. For example, we know exactly how many bytes worth of objects are currently alive in the current generation. (In the GC speaks, we call these promoted bytes, because they are the bytes that get promoted to the next generation).
3. Using that data, comparing with the configuration, we can detect if we are currently hitting the interesting scenario (e.g. the ephemeral leaking scenario in the blog), and so we trigger the data collection process in a blocking manner so that the heap won’t change.
4. The data collection process could be either walking the heap and report the objects as traces through event pipe, or taking a heap dump, or both.
5. In case we want the trace in step 4, we will first emit the GenAwareBegin event, then walk the heap, then emit the GenAwareEnd event, these events together delineate where the heap walk begins and ends.
6. With those events, PerfView can detect the trace contains a GenAware heap collection, and it will be able to produce an analysis as the blog post shows.

Author:	LakshanF
Assignees:	LakshanF
Labels:	area-NativeAOT-coreclr
Milestone:	8.0.0