Uh oh!
There was an error while loading. Please reload this page.
EventSource startup initialization - #106014
Conversation
Fixesdotnet#105845 Previously MetricsEventSource wasn't being created for apps that didn't ever create a Meter. This caused a chicken-and-egg problem for RuntimeMetrics which weren't created until MetricsEventSource started a tracing session. This change ensures that MetricsEventSource will be created on demand if ETW, EventPipe, or EventListener based tooling starts a tracing session. I took some extra effort to create the EventSource in a deferred fashion to avoid eager loading System.Diagnostics.DiagnosticSource.dll when it might never be needed. Aside from the fix there were some small improvements: - Moved NativeRuntimeEventSource to initialize in the same place as other startup EventSources - Removed a useless lock(EventListener.EventListenersLock) around EventPipe eventProvider registration
ba0c870 to
85ff378CompareUh oh!
There was an error while loading. Please reload this page.
noahfalk
commented
Aug 7, 2024
I think this is ready for review now. The CI failures appear spurious. |
noahfalk
commented
Aug 7, 2024
@LakshanF@MichalStrehovsky - this change also adjusted the NativeAOT startup slightly by moving the ModuleInitializer attribute from RuntimeEventSource.Initialize() to EventSource.InitializeDefaultEventSources(). @elinor-fung - this change adjusts the startup path you were just editing earlier this week. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
brianrob
commented
Aug 8, 2024
I suspect that I just missed something here, but want to check - I see where you register the listeners for ETW and EventPipe and trigger creation if/when a command comes in. How is EventListener handled? Something will need to create the MetricsEventSource so that OnEventSourceCreated gets called. I'm assuming you have this covered and I just missed it. |
noahfalk
commented
Aug 8, 2024
Yep, thats this part right here to handle EventListener callbacks: |
MichalStrehovsky
commented
Aug 8, 2024
This means any app with EventSourceSupport=true will pay for this in terms of size, but it doesn't look terrible. I triggered a rt-sz run and it seems like we'll have a 30 kB regression in It doesn't make a huge difference in EventSource cost ( |
brianrob
commented
Aug 8, 2024
Thanks! LGTM. |
05595e6 to
4adc304Compare4adc304 to
daeb128Comparenoahfalk
commented
Aug 8, 2024
Thanks for the feedback, it should all be addressed now. Once CI confirms no new issues I'll merge. |
Fixes#105845
Previously MetricsEventSource wasn't being created for apps that didn't ever create a Meter. This caused a chicken-and-egg problem for RuntimeMetrics which weren't created until MetricsEventSource started a tracing session. This change ensures that MetricsEventSource will be created on demand if ETW, EventPipe, or EventListener based tooling starts a tracing session. I took some extra effort to create the EventSource in a deferred fashion to avoid eager loading System.Diagnostics.DiagnosticSource.dll when it might never be needed.
Aside from the fix there were some small improvements: