-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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 Mono EventPipe Sample Profiler support. #47858
Merged
lateralusX
merged 6 commits into
dotnet:master
from
lateralusX:lateralusX/add-mono-eventpipe-sample-profiler
Feb 12, 2021
Merged
Add Mono EventPipe Sample Profiler support. #47858
lateralusX
merged 6 commits into
dotnet:master
from
lateralusX:lateralusX/add-mono-eventpipe-sample-profiler
Feb 12, 2021
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
lateralusX
force-pushed
the
lateralusX/add-mono-eventpipe-sample-profiler
branch
from
February 8, 2021 09:03
14a0a01
to
7581cfd
Compare
lateralusX
changed the title
WIP: Add Mono EventPipe Sample Profiler support.
Add Mono EventPipe Sample Profiler support.
Feb 8, 2021
lambdageek
approved these changes
Feb 8, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
lateralusX
requested review from
BrzVlad,
CoffeeFlux,
marek-safar,
naricc,
thaystg and
vargaz
as code owners
February 9, 2021 12:04
naricc
reviewed
Feb 9, 2021
naricc
approved these changes
Feb 11, 2021
Replace mono_gc_stop|restart_world with mono_stop|restart_world. Keep in gc-internals.h until we move STW code into none GC dependent code.
lateralusX
force-pushed
the
lateralusX/add-mono-eventpipe-sample-profiler
branch
from
February 12, 2021 10:37
10028b9
to
4799faf
Compare
ghost
locked as resolved and limited conversation to collaborators
Mar 14, 2021
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement support for EventPipe Sample Profiler on Mono inline with CoreClr Sample Profiler behaviour. By default CoreClr sample profiler tries to run at 1000 hertz (every ms) and on each sample it will stop runtime, snap callstacks for all managed threads, submit EventPipe sample profile events and resume runtime. Doing a full stop/restart of the runtime on every sample could be quite invasive, but is probably the most portable way of implementing it working on most platforms.
This PR implements the same logic, but on Mono runtime, stopping the runtime, record all callstacks for all managed threads that should be sampled, restart runtime and then write all sample profile events into EventPipe. Note that events are written after the runtime has resumed since all code executed when runtime is stopped needs to be async safe (needed when running in preemptive mode) so we can't call into EventPipe at that point.
Going forward we should investigate alternative ways to do sample profiling depending on underlying platform and OS support. Currently implementation will work on all supported platforms, but it will not be as accurate as it could be (especially when using safe points and coop enabled runtime) and impacts measured target. Mono's profiler uses Signals/SuspendThread and for platforms supporting these API's, that could be an alternative implementation. It could also be worth to look into CPU hardware counters using ETW kernel log session on Windows and perf_event_open on Linux.