[Tests] Update GC SegmentEvents validation

[mdh1418]

Fixes #3143

With the new GC introduced in .NET 7, there are no longer any GC segments being freed, so the GCFreeSegment event is not guaranteed to fire during GC. As the GCFreeSegment event is documented to track when a garbage collection segment has been released, and because Perfview does not utilize GCFreeSegment/GCCreateSegment events, it seems more appropriate to adjust expectations for what GC events are fired rather than forcing GCFreeSegment events to fire for "analogous" events.

Moreover, there is a new CommittedUsage events that shows GC committed memory and breaks down what the memory is used for. As such, GCFreeSegment/GCCreateSegment is no longer needed.

[noahfalk]

Do we also expect the GCCreateSegmentEvents not to be generated? The test appears to have stopped checking both but the comments only mention GCFreeSegment events stopped. Assuming CreateSegment events are still expected I'd suggest only removing the GCFreeSegmentEvents portion of the check.

I don't think we need to make it conditional on major version either. As long as the test won't start failing when run on older versions it should be fine.

[mdh1418]

In the runtime, there are still technically instances of firing GCCreateSegment_V1 and GCFreeSegment_V1 events. However, from offline discussions summarized in #3143 (comment), this PR is driving towards removing expectations of those events being fired during the new GC.

Since both GCCreateSegment and GCFreeSegment are documented to specifically mean GC segments being created/released, and since the new GC uses regions, I figured that it would be better keep those events to specifically mean GC segments.

[noahfalk]

if both of those events are affected thats np, the comments elsewhere had given a false impression that the FreeSegment events were the only one impacted.

[mdh1418]

@cshung Would it make sense to have an expectation for a positive number of CommittedUsage events now during a GC for .NET 8+? Wondering if there is a parallel with the old GC's expectation for positive number of GC*SegmentEvents for the new GC.

Adding a validator for CommittedUsage "worked", but I'm not sure if it is supposed to be a guarantee now during a normal GC

Func<EventPipeEventSource, Func<int>> _DoesTraceContainEvents = (source) => {
    int GCCommittedUsageEvents = 0;
    source.Clr.GCDynamicEvent.GCCommittedUsage += (eventData) => GCCommittedUsageEvents += 1;

    int GCAllocationTickEvents = 0;
    source.Clr.GCAllocationTick += (eventData) => GCAllocationTickEvents += 1;

    return () => {
        Logger.logger.Log("Event counts validation");

        bool GCCommittedUsageResult = GCCommittedUsageEvents > 0;
        Logger.logger.Log("GCCommittedUsageResult: " + GCCommittedUsageEvents);

        Logger.logger.Log("GCAllocationTickEvents: " + GCAllocationTickEvents);
        bool GCAllocationTickResult = GCAllocationTickEvents > 0;
        Logger.logger.Log("GCAllocationTickResult: " + GCAllocationTickResult);

        bool GCCollectResults = GCCommittedUsageResult && GCAllocationTickResult;
        Logger.logger.Log("GCCollectResults: " + GCCollectResults);

        return GCCollectResults ? 100 : -1;
    };
};

But in order for this to be added, it would need the Microsoft.Diagnostics.Tracing.TraceEvent version to be bumped. When might be reasonable to bump that in this repo @mikem8361
If neither that version should be bumped nor should there be a parallel expectation with CommittedUsage events, then I'll reduce the validation to just the GC allocation tick event

[mikem8361]

It sounds reasonable to me but I'm not an expert on TraceEvent.

[cshung]

@cshung Would it make sense to have an expectation for a positive number of CommittedUsage events now during a GC for .NET 8+?

Short answer: Yes.
Long answer: It depends on version and platforms.

Here are some of the specifics:

Event counts:

• CommittedUsage event is introduced in this commit. This commit is .NET 8.
• We have two CommittedUsage events before and after a blocking GC for regions.
• We have one CommittedUsage event before a background GC for regions.
• We don't have any CommittedUsage event for segments before this commit. This commit is .NET 10
• After that commit, we have exactly the same CommittedUsage events counts for segments as well.

Version and platforms:

• For .NET 7+, 32 bit platforms (e.g. ARM/x86) or osx uses segments, other platforms uses regions by default.
• Under .NET 7, NativeAOT used segments. Support for NativeAOT to use regions is available for .NET 8+ after this commit.

All of these can be overridden if user uses the standalone GC, you can even use regions for .NET 6.