Uh oh!
There was an error while loading. Please reload this page.
[runtime-async] Fix timestamp instrumentation - #127662
Conversation
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag |
There was a problem hiding this comment.
Pull request overview
This PR adjusts the runtime-async async-debugger instrumentation so that newly-created continuation chains get fresh timestamps at suspension time (instead of inheriting the timestamp of the currently-running continuation), and removes now-unneeded timestamp propagation logic tied to follow-up scheduling.
Changes:
- Removed the
Task.TryAddRuntimeAsyncContinuationChainTimestamps(Continuation chain, Continuation timestampSource)overload to avoid propagating an “old” timestamp to newly allocated continuation nodes. - Simplified
AsyncDebugger.HandleSuspended/InstrumentedHandleSuspendedto always timestamp based on the suspended chain head (sentinel’sNext) without a separate timestamp source. - Removed the
SuspendRuntimeAsyncContext(ref AsyncDispatcherInfo, ...)/SuspendAsyncContext(ref AsyncDispatcherInfo, ...)path that previously timestamped the remaining chain when a follow-up continuation was queued.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs | Removes the timestamp-source-based chain timestamping helper, leaving chain timestamping to use a fresh suspension-time timestamp. |
| src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs | Updates runtime-async instrumentation to timestamp suspended chains without using a “source continuation”, and removes the follow-up-action timestamping/suspend helper calls. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
lateralusX
commented
May 4, 2026
You will need to rebase and test this on top of #127238. |
lateralusX
commented
May 4, 2026
We should probably also add some test to see if we could guard this specific scenario as well. |
Uh oh!
There was an error while loading. Please reload this page.
rcj1
commented
May 12, 2026
/ba-g timeouts |
We need to ensure that new continuations are timestamped at suspension time. In an app with an async chain starting with, say, Main,
curContinuationandnewContinuationwill both belong to Main upon resuming Main in DispatchContinuations. The async chain int_runtimeAsyncAwaitState.SentinelContinuation!.Nexthas been built by the JIT viaAsyncSuspendand contains newly allocated continuations for the methods above Main in the stack. These should receive a new timestamp, not that of Main.I don't think we need to add timestamps in
QueueContinuationFollowUpActionIfNecessary; they have already been added inHandleSuspended.Fixes the issue of all the timestamps being the same.
Benchmark #123727 (comment):
New: 387.4 ms
Old: 404.2 ms