Add feature flag which controls Event Tracing support

[marek-safar]

On some workloads ETW is not supported at all, on some we'd like to disable it by default due to size impact. There is not "feature flag" to do it right now.

We should introduce something like RuntimeFeature.IsEvenTracingSupported to allow illinker to remove any event tracing code and metadata automatically.

This flag would need to be used to guard any EventSource like calls and attributes but that should be quite straight forward code replace in the framework. The ETW today mostly relies on instance IsEnabled method check which is not suitable for substitution as illinker as it has several overloads and would require all EventSource derived constructors to be kept with their dependencies.

@eerhardt @vitek-karas

Tagging subscribers to this area: @vitek-karas, @swaroop-sridhar
Notify danmosemsft if you want to be subscribed.

[stephentoub]

Does that mean that every logging site would now need even more boilerplate:

if (RuntimeFeature.IsEventTracingSupported && MyEventSource.Log.IsEnabled) { ... actual logging ... }

? The existing guard is annoying enough, but largely unavoidable (especially if the actual call incurs cost due to computing args); it'd be really good if we could come up with a way to avoid needing the extra clause at every logging site. Some libraries do a ton of logging and it'd be nice to avoid all the extra cruft.

[stephentoub]

For example, maybe we move to a static IsEnabled which does the runtime feature check, along with a lazily-initialized Log? Or maybe there's an attribute-based scheme where we can put some attribute on MyEventSource or Log or even better the base IsEnabled that ties it to this runtime feature from the linker's perspective?

[vitek-karas]

I think we should do this in two layers:

• The implementation - where we would make sure that if event source is turned off, the public API is still there, but inside it doesn't do anything - and none of the code of the internal implementation gets pulled in. This can be done with the static property as suggested above.
• The call sites - once we have the above this is a little less important as the size impact should not be that big. But it would still be nice to have that. If we can solve Non-virtual, instance methods that return a constant expression should be inlined linker#1243 then it should be possible to do this without modifying the callsites.

Note that we need the implementation guards regardless as we can't rely on all callsites to correctly wrap the call with the If(enabled).

Tagging subscribers to this area: @tarekgh, @tommcdon, @pjanotti
Notify danmosemsft if you want to be subscribed.

[marek-safar]

The importance of the static property is that gives us the most savings. Relying on instance version of IsEnabled is not great because it means we have to keep whole constructors chain for every custom EventSource and these constructors can bring dependencies and so on.