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

Add the concept of "notification profilers" to the runtime #53122

Merged
merged 18 commits into from
Jun 15, 2021

Conversation

davmason
Copy link
Member

This allows multiple profilers to register if they only request a subset of profiler behavior that is multiple profiler safe - ReJIT, IL modification, ELT stubs, etc are forbidden for these profilers.

The basic approach is relatively straightforward, instead of calling one profiler back we call back a list of them.

Items left:
Testing:

  • Run runtime and profiler tests for regressions
  • Stress test profilers attaching and detaching
  • Run all runtime tests with notification profiler attached
  • Test multiple profilers each with an eventpipe session

Documentation

  • Write description of feature
  • Write and publish sample to dotnet/samples

@davmason davmason added this to the 6.0.0 milestone May 22, 2021
@davmason davmason requested review from noahfalk and a team May 22, 2021 08:55
@davmason davmason self-assigned this May 22, 2021
@ghost
Copy link

ghost commented May 22, 2021

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

This allows multiple profilers to register if they only request a subset of profiler behavior that is multiple profiler safe - ReJIT, IL modification, ELT stubs, etc are forbidden for these profilers.

The basic approach is relatively straightforward, instead of calling one profiler back we call back a list of them.

Items left:
Testing:

  • Run runtime and profiler tests for regressions
  • Stress test profilers attaching and detaching
  • Run all runtime tests with notification profiler attached
  • Test multiple profilers each with an eventpipe session

Documentation

  • Write description of feature
  • Write and publish sample to dotnet/samples
Author: davmason
Assignees: davmason
Labels:

area-Diagnostics-coreclr

Milestone: 6.0.0

Copy link
Contributor

@josalem josalem left a comment

Choose a reason for hiding this comment

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

I didn't look too closely at the thread safety around loading/unloading, but the general gist of the work looks good to me! Excited to see where this goes 🚀

src/coreclr/inc/profilepriv.h Show resolved Hide resolved
src/coreclr/inc/profilepriv.h Show resolved Hide resolved
Copy link
Member

@noahfalk noahfalk left a comment

Choose a reason for hiding this comment

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

This looks good to me! Comments inline on some small stuff I noticed.

COR_PRF_MONITOR_CLR_EXCEPTIONS |
COR_PRF_ENABLE_STACK_SNAPSHOT |
COR_PRF_USE_PROFILE_IMAGES |
COR_PRF_DISABLE_ALL_NGEN_IMAGES,
Copy link
Member

Choose a reason for hiding this comment

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

Aren't some of these side-effecting? Since the notification profilers are intended to be SxS perhaps we should scope it back to the options that are allowable on attach?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's a good conversation to have. I was taking the approach to not ban any side effects, but rather ban side effects that would be non trivial to implement (ELT hooks) or are hard to provide in a way that is consistent and reproducible (IL rewriting).

I am worried about being too limiting in what scenarios we support. It is unfortunate to look back in a few releases and think "we could have done it except we arbitrarily decided to block this thing that is actually safe"

Copy link
Member

Choose a reason for hiding this comment

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

I don't mind taking the risk as long as you think you've had suitable time to consider it and test the additional APIs : )

Copy link
Member

Choose a reason for hiding this comment

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

Although one other thought, if we are going to allow side-effects then 'NotificationOnly' feels like a misleading name. What about calling them "SxS", "Cooperative", or another name similar to that?

src/coreclr/inc/corprof.idl Outdated Show resolved Hide resolved
src/coreclr/inc/profilepriv.h Outdated Show resolved Hide resolved
src/coreclr/inc/profilepriv.inl Outdated Show resolved Hide resolved
src/coreclr/inc/profilepriv.inl Outdated Show resolved Hide resolved
src/coreclr/vm/profilinghelper.cpp Outdated Show resolved Hide resolved
src/coreclr/inc/profilepriv.inl Outdated Show resolved Hide resolved
src/coreclr/vm/profilinghelper.cpp Show resolved Hide resolved
src/coreclr/vm/profilinghelper.cpp Outdated Show resolved Hide resolved
src/coreclr/vm/profilinghelper.cpp Outdated Show resolved Hide resolved
@davmason davmason marked this pull request as ready for review June 14, 2021 20:48
SArray doesn't work with classes that aren't POD since it doesn't initialize the backing memory and uses operator= not the constructor to assign elements
@davmason davmason merged commit ab71c1f into dotnet:main Jun 15, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Jul 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants