the way GC recognizes which ETW events are enabled/disabled does not work for multiple consumers scenario

[Maoni0]

since GC lives separately from the VM side, we keep track of which events are enabled/disabled on the GC side so we can test if an event is enabled quickly. we track this by keyword/level in EtwCallback (vm\eventtrace.cpp) -

        GCEventKeyword keywords = static_cast<GCEventKeyword>(MatchAnyKeyword);
        GCEventLevel level = static_cast<GCEventLevel>(Level);
        GCHeapUtilities::RecordEventStateChange(!!bIsPublicTraceHandle, keywords, level);

however, this does not work when there are multiple consumers - one consumer might disable some events but another consumer still wants them. we need to keep track of this per session, ie, each time EtwCallback is called to enable, we need to increment the counter for these keywords/level and decrement accordingly when EtwCallback is called to disable, and only truly disable if no consumer wants them. I don't think there can be a very large # of sessions so we could also just have a datastructure that records what each session wanted and check with each one to see if we should inform the GC side of the disabled/enabled events.

CC @benmwatson, @brianrob

[tamlin-mike]

In this case I suspect it'd be more prudent to follow the KISS principle.

While refcounting might look nice at first glance, it only works (reliably) when everything is synchronized, and synchronization is -- as many have experienced -- easy to get wrong.
Example: When (not if, when) a consumer crashes, how would all its refcounted subscriptions get decremented?

As for resource consumption: a single 4KB page can hold 32768 flags. That amount of of bool's could keep you busy for the next decades, to implement events for, and document. :-)

TL;DR; I believe keeping the "what's enabled" cache per-client is the best of the options. It's easy to implement, review and pehaps most importantly maintain.