Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setup support for managed runtime events #87785

Merged
merged 24 commits into from
Jul 6, 2023
Merged

Conversation

LakshanF
Copy link
Member

@LakshanF LakshanF commented Jun 19, 2023

Initial work to enable managed runtime events in EventPipe. The work includes

@LakshanF LakshanF added this to the 8.0.0 milestone Jun 19, 2023
@LakshanF LakshanF self-assigned this Jun 19, 2023
@LakshanF LakshanF marked this pull request as draft June 19, 2023 21:50
@ghost
Copy link

ghost commented Jun 19, 2023

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

Issue Details

Initial work to enable managed runtime events in EventPipe.

Author: LakshanF
Assignees: LakshanF
Labels:

area-NativeAOT-coreclr

Milestone: 8.0.0

@elinor-fung
Copy link
Member

Initial work to enable managed runtime events in EventPipe.

Is the plan to also fire these via ETW (on Windows)?

Wire up additional native GC events that will be fired in Windows. #87445 needs to be completed for these to be seen from Linux.

I'd expect only the events that go through ETW::GCLog to not be fired on non-Windows and direct usage of the FireEtw*/EventPipeWriteEvent* functions should fire through EventPipe on all platforms. Are you seeing that event the FireEtw*/EventPipeWriteEvent* ones firing aren't on Linux?

@LakshanF
Copy link
Member Author

I'd expect only the events that go through ETW::GCLog to not be fired on non-Windows and direct usage of the FireEtw*/EventPipeWriteEvent* functions should fire through EventPipe on all platforms. Are you seeing that event the FireEtw*/EventPipeWriteEvent* ones firing aren't on Linux?

I can see events GCGlobalHeapHistory and GCHeapStats getting fired in Linux.

Opened #88162 for adding these events to ETW.

LakshanF and others added 2 commits June 30, 2023 04:29
Co-authored-by: Elinor Fung <elfung@microsoft.com>
Copy link
Member

@elinor-fung elinor-fung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm assuming the dotnetruntime.cpp functions added for writing the events is lifted from the auto-generated ones for coreclr, so I didn't look at them much.

cc @davmason - if you are interested in the tracing/eventpipe test changes


#ifdef FEATURE_PERFTRACING

// We will do a no-op for events in the disabled EventPipe This is similar to the way eventpipe checks if the provider and an event is enabled before firting the event, and no-op otherwise.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we not make the managed side conditionally call the runtime import based on event source support and let trimming do its thing? Or are we trying to keep the event source feature switch and disabled/enabled eventing native library independent from one another?

Just thinking that the disabled and enabled definitions might be getting a bit unwieldy and we could presumably remove the disabled ones only called from managed (maybe also a really small size decrease).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the issue #82231 with this as well.

{
{ "MyEventSource", new ExpectedEventCount(100_000, 0.30f) },
{ "Microsoft-Windows-DotNETRuntimeRundown", -1 },
{ "Microsoft-DotNETCore-SampleProfiler", -1 }
};

private static Dictionary<string, ExpectedEventCount> _expectedEventCountsNativeAOT = new Dictionary<string, ExpectedEventCount>()
{
{ "MyEventSource", 100_000 },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does coreclr need the ExpectedEventCount error, but nativeaot does not?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe coreclr error range tolerance is an artifact of earlier times when EventPipewas dropping events. NativeAOT doesn't support rundown and sampleprofiler and followed a policy of not touching coreclr testing.

@LakshanF LakshanF merged commit b78345e into dotnet:main Jul 6, 2023
@LakshanF LakshanF deleted the RuntimeEvents branch July 6, 2023 12:29
radical added a commit to radical/runtime that referenced this pull request Jul 6, 2023
`tracing/eventpipe/simpleruntimeeventvalidation`:

```
          Generated app bundle at /root/helix/work/workitem/e/tracing/eventpipe/simpleruntimeeventvalidation/simpleruntimeeventvalidation/WasmApp/
        Incoming arguments: --run simpleruntimeeventvalidation.dll
        Application arguments: --run simpleruntimeeventvalidation.dll
        console.info: Initializing dotnet version 8.0.0-ci commit hash f47b553f129cfa7f006cb1a2f2088112c5ca0112
          0.0s: ==TEST STARTING==
          0.1s: System.PlatformNotSupportedException: System.Diagnostics.Process is not supported on this platform.
           at System.Diagnostics.Process.GetCurrentProcess()
           at Tracing.Tests.Common.IpcTraceTest.Validate(Boolean enableRundownProvider)
           at Tracing.Tests.Common.IpcTraceTest.RunAndValidateEventCounts(Dictionary`2 expectedEventCounts, Action eventGeneratingAction, List`1 providers, Int32 circularBufferMB, Func`2 optionalTraceValidator, Boolean enableRundownProvider)
          0.1s: ==TEST FINISHED: FAILED!==
        test-main.js exiting simpleruntimeeventvalidation.dll with result -1
        console.info: WASM EXIT -1
```

This was added in dotnet#87785, but got
merged on red.
radical added a commit that referenced this pull request Jul 7, 2023
`tracing/eventpipe/simpleruntimeeventvalidation`:

```
          Generated app bundle at /root/helix/work/workitem/e/tracing/eventpipe/simpleruntimeeventvalidation/simpleruntimeeventvalidation/WasmApp/
        Incoming arguments: --run simpleruntimeeventvalidation.dll
        Application arguments: --run simpleruntimeeventvalidation.dll
        console.info: Initializing dotnet version 8.0.0-ci commit hash f47b553f129cfa7f006cb1a2f2088112c5ca0112
          0.0s: ==TEST STARTING==
          0.1s: System.PlatformNotSupportedException: System.Diagnostics.Process is not supported on this platform.
           at System.Diagnostics.Process.GetCurrentProcess()
           at Tracing.Tests.Common.IpcTraceTest.Validate(Boolean enableRundownProvider)
           at Tracing.Tests.Common.IpcTraceTest.RunAndValidateEventCounts(Dictionary`2 expectedEventCounts, Action eventGeneratingAction, List`1 providers, Int32 circularBufferMB, Func`2 optionalTraceValidator, Boolean enableRundownProvider)
          0.1s: ==TEST FINISHED: FAILED!==
        test-main.js exiting simpleruntimeeventvalidation.dll with result -1
        console.info: WASM EXIT -1
```

This was added in #87785, but got
merged on red.
@ghost ghost locked as resolved and limited conversation to collaborators Aug 5, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants