Always write sample events in EventPipe based on sample frequency. #58720
Conversation
If no managed frames (including helper frames) are located on stack, sample was dropped and not emitted into EventPipe. This cause issues in tooling that try to do thread time calculations based on sample, especially in cases where embedded threads returned to native code during several samples before calling back into runtime. In such scenarios the last sampled event would be prolonged, giving false information that that stackframe lasted much longer than it really did. Always writing samples into EventPipe will also visualize time an attached thread spend outside of runtime, not running managed code.
ghost
added
the
Only include external samples still on top fram (no callstack) or managed/external samples includig a callstack.
|
//CC @josalem |
josalem
left a comment
josalem
left a comment
There was a problem hiding this comment.
This is a good step while we rethink some of the semantics of our stackwalker. I wish there was a way to indicate this state without sending sample events, but the Sample Profiler provider doesn't have that capability and I'm not sure it's worth adding at this moment.
CC @brianrob since this will impact PerfView's parsing of stack samples (for the better)
|
Perfview will collect these as unmanaged code right below the thread since there is no callstack associated with sample event, so it already handles the case, but It would be good if we could have option in Perfview to exclude events without available callstacks in for example calltree, right now you can exclude UNAMANGED_CODE_TIME, but that will exclude all occurrences, would be good to be able to exclude these occurrences happening when UNAMANGED_CODE_TIME represent a sample event in external code without any callstack. |
|
/backport to release/6.0 |
|
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1210361775 |
2 participants
If no managed frames are located on stack, sample was dropped and not emitted into EventPipe by sample profiler. This cause issues in tooling that try to do thread time calculations based on sample, especially in cases where embedded threads returned to native code during several samples before calling back into runtime. In such scenarios the last sampled event would be prolonged, giving false information that that stack frame lasted much longer than it really did.
Always writing samples into EventPipe will also visualize time an attached thread spend outside of runtime, not running managed code.
Fix should open up for better visualization as described in dotnet/android#6243.
We can do similar fix to CoreCLR as well:
runtime/src/coreclr/vm/eventing/eventpipe/ep-rt-coreclr.cpp
Line 117 in db04259
but I'm splitting fixes into different PR's since MonoVM's embedding scenario makes this scenario much more likely to occur (already observed in different embedding scenarios) than CoreCLR.