JIT: Move Thread sync and exec context save/restore to happen around runtime async bodies #121448

jakobbotsch · 2025-11-07T14:27:13Z

This fixes an issue where there was a behavioral difference between async1 and async2 for async to sync runtime async calls. Before this PR the JIT would always save and restore contexts around awaits of task-returning methods, regardless of whether they were implemented as runtime async functions or not. That does not match async1: in async1, the context save and restore happens around the body in each async method. The former logic was an optimization, but the optimization is only correct for runtime async to runtime async calls.

We cannot in general know if a callee is implemented by runtime async or not, so we have to move the context save/restore to happen around the body of all runtime async methods.

An example test program that saw the behavioral difference before is the following:

using System;
using System.Threading;
using System.Threading.Tasks;

public class Program
{
    static void Main()
    {
        Foo().GetAwaiter().GetResult();
    }

    static async Task Foo()
    {
        SynchronizationContext.SetSynchronizationContext(new MySyncCtx(123));
        Console.WriteLine(((MySyncCtx)SynchronizationContext.Current).Arg);
        await Bar();
        Console.WriteLine(((MySyncCtx)SynchronizationContext.Current).Arg);
    }

    static Task Bar()
    {
        SynchronizationContext.SetSynchronizationContext(new MySyncCtx(124));
        return Task.CompletedTask;
    }

    class MySyncCtx(int arg) : SynchronizationContext
    {
        public int Arg => arg;
    }
}

Async1: 123 124
Runtime async before: 123 123
Runtime async after: 123 124

…ound-body

dotnet-policy-service · 2025-11-07T14:28:38Z

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

jakobbotsch · 2025-11-07T14:31:54Z

FYI @VSadov @davidwrighton

Still not ready -- needs more testing, and I need to introduce the test case. But this is a heads up that some changes are incoming around the save/restore behavior.

davidwrighton · 2025-11-07T21:04:48Z

This doesn't feel right around Sync/Execution save and restore at suspension points. It looks correct for save/restore around the initial call, but the async callsite on suspension behavior looks wrong to me. Let me see if I can write up a few test cases. Do we have a convenient async testbed for these sorts of tests? In general, I think save/restore at the top level makes sense, but using that context saved at the top level during a suspend as the "captured" context I think is wrong.

jakobbotsch · 2025-11-07T21:47:01Z

Let me see if I can write up a few test cases. Do we have a convenient async testbed for these sorts of tests?

src/tests/async is where they live, there is a synchronization context test.

using that context saved at the top level during a suspend as the "captured" context I think is wrong.

We aren't doing that, we are getting new contexts from Thread.CurrentThread for saving inside the continuation (and for restoring on resumption). Then we restore the thread ones from the ones we saved at the beginning.
(This path is currently pretty inefficient, we could have a single helper to save the current contexts and restore the old ones, but I left that for a future PR)

davidwrighton · 2025-11-08T01:13:19Z

@jakobbotsch Ah, I was confused by some of the terminology around the JIT here. What happens if there is an exception while restoring the old contexts on suspension? Are we still inside the try/finally which will ALSO attempt to restore the old contexts? Notably, restoring a context involves running arbitrary code since you can have an AsyncLocal with value changed notifications, and what is the behavior if they throw? I don't want us to try to run the ExecutionContext restore twice. I have no idea what that would do. Now that I've looked at this, I think otherwise its all good.

jakobbotsch · 2025-11-08T12:37:13Z

What happens if there is an exception while restoring the old contexts on suspension? Are we still inside the try/finally which will ALSO attempt to restore the old contexts? Notably, restoring a context involves running arbitrary code since you can have an AsyncLocal with value changed notifications, and what is the behavior if they throw? I don't want us to try to run the ExecutionContext restore twice. I have no idea what that would do. Now that I've looked at this, I think otherwise its all good.

No, suspension/resumption code is not inside the try clause. So if OnValuesChanges throws we won't retry the restore.
Still, it is a good point about exceptions during suspension. I opened #121465 to investigate that further.

jakobbotsch · 2025-11-10T16:07:02Z

The failures all look like infra issues (QUIC failure, OSX timeouts and "The SSL connection could not be established" failures).

cc @dotnet/jit-contrib PTAL @AndyAyersMS @VSadov

jakobbotsch · 2025-11-10T16:09:58Z

src/coreclr/jit/async.cpp

-            DISPSTMT(restoreStmt);
+    for (BasicBlock* block : Blocks())
+    {
+        AddContextArgsToAsyncCalls(block);


There are two new well known args for the synchronization context and execution context. This is modelling the fact that there is a use of these two values when we later expand the async call; we need to restore the Thread fields on the suspension path from these values.

jakobbotsch · 2025-11-10T16:10:55Z

src/coreclr/jit/async.cpp

+    CORINFO_CALL_INFO callInfo = {};
+    callInfo.hMethod           = captureCall->gtCallMethHnd;
+    callInfo.methodFlags       = info.compCompHnd->getMethodAttribs(callInfo.hMethod);
+    impMarkInlineCandidate(captureCall, MAKE_METHODCONTEXT(callInfo.hMethod), false, &callInfo, compInlineContext);


I initially was adding the try-fault and doing return merging from fgAddInternal + morph, but I really want to be able to inline these helpers, so I moved it here and taught the pass to do its own return merging.

Consider adding a stress mode even if CORINFO_ASYNC_SAVE_CONTEXTS is not set that runs the return merging logic anyways? Would require adding a stress mode arg to CreateReturnBB.

jakobbotsch · 2025-11-10T16:13:46Z

src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs

-        private static void CaptureContinuationContext(SynchronizationContext syncCtx, ref object context, ref ContinuationFlags flags)
+        private static void CaptureContinuationContext(ref object continuationContext, ref ContinuationFlags flags)
        {
+            SynchronizationContext? syncCtx = Thread.CurrentThreadAssumedInitialized._synchronizationContext;


We now just get it from the Thread object here; it is relying on the fact that if the callee was runtime async, then it has restored the fields already. This is matching the behavior as Task.UnsafeSetContinuationForAwait which also happens as the continuation gets created. (And importantly, when the callee was not async we get a possibly-changed sync context here.)

CurrentThreadAssumedInitialized was safe here because any entry into runtime async would go through a Task-returning thunk, which would touch CurrentThread.
If the thunk no longer captures/restores, this might need to use CurrentThread.

If we remove it from the thunks then we should just replace it by an explicit call to initialize the current thread. For now we can just keep it in the thunks though.

jakobbotsch · 2025-11-10T16:15:43Z

src/coreclr/jit/gentree.cpp

 //   and generally never on stack.
 //
-regNumber CallArgs::GetCustomRegister(Compiler* comp, CorInfoCallConvExtension cc, WellKnownArg arg)
+bool CallArgs::GetCustomRegister(Compiler* comp, CorInfoCallConvExtension cc, WellKnownArg arg, regNumber* reg)


Changed this to add the possibility of well known args that do not affect the ABI computation. That allows adding arbitrary uses that do not affect how other args are passed.
I'm using it for the new AsyncExecutionContext and AsyncSynchronizationContext, and I also put StackArrayLocal under this category (even though I think the call is always expanded out).

Copilot

Pull Request Overview

This PR refactors the async context (ExecutionContext and SynchronizationContext) handling for runtime async methods. The changes move from a per-await-call context save/restore model to a method-level context management approach, simplifying the implementation and enabling runtime async support by default.

Key Changes

Method-level context management: ExecutionContext and SynchronizationContext are now saved once at method entry and restored at method exit/exception, rather than around each individual async call.
Simplified async call handling: Removed per-call suspended indicator logic and execution context tracking fields from AsyncCallInfo.
Enabled by default: Runtime async support is now enabled by default via the RuntimeAsync configuration flag.

Reviewed Changes

Copilot reviewed 19 out of 19 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/tests/async/synchronization-context/synchronization-context.cs	Adds test for async-to-sync context switching behavior
src/tests/async/Directory.Build.targets	Removes file that disabled async tests for certain configurations
src/coreclr/vm/method.hpp	Adds `RequiresAsyncContextSaveAndRestore()` method and fixes typo in comment
src/coreclr/vm/jitinterface.cpp	Passes `CORINFO_ASYNC_SAVE_CONTEXTS` flag to JIT for eligible methods
src/coreclr/jit/morph.cpp	Refactors `GetCustomRegister` to return bool and updates well-known arg names
src/coreclr/jit/lclmorph.cpp	Removes async suspended indicator local handling
src/coreclr/jit/importercalls.cpp	Simplifies async call setup by removing per-call context save/restore logic
src/coreclr/jit/importer.cpp	Removes tailcall restrictions for task awaits and adds new context args to inline handling
src/coreclr/jit/gentree.h	Refactors `AsyncCallInfo` structure and renames well-known args
src/coreclr/jit/gentree.cpp	Updates `GetCustomRegister` signature and removes obsolete methods
src/coreclr/jit/flowgraph.cpp	Minor comment punctuation fix
src/coreclr/jit/fginline.cpp	Corrects type and preserves async flag for inlined async calls
src/coreclr/jit/compiler.hpp	Removes async suspended indicator local handling from visitor
src/coreclr/jit/compiler.h	Adds method-level context locals and removes per-call tracking field
src/coreclr/jit/async.h	Renames field and adds `RestoreContexts` method
src/coreclr/jit/async.cpp	Major refactoring: implements method-level context save/restore with try/fault wrapper
src/coreclr/inc/corinfo.h	Adds `CORINFO_ASYNC_SAVE_CONTEXTS` flag
src/coreclr/inc/clrconfigvalues.h	Enables runtime async by default
src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs	Updates parameter names and removes sync context argument from continuation context capture

Copilot · 2025-11-10T16:17:37Z

src/coreclr/jit/async.cpp

+//   Create IR to restore contexts on suspension.
+//
+// Parameters:
+//   block     - Block that contains the async calll


Typo in comment: "calll" should be "call".

Suggested change

// block - Block that contains the async calll

// block - Block that contains the async call

Copilot · 2025-11-10T16:17:38Z

src/coreclr/inc/clrconfigvalues.h


 // Runtime-async
-RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_RuntimeAsync, W("RuntimeAsync"), 0, "Enables runtime async method support")
+RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_RuntimeAsync, W("RuntimeAsync"), 1, "Enables runtime async method support")


[nitpick] This change enables runtime async by default (changing from 0 to 1). While this may be intentional for this PR, consider whether this should be behind a feature flag or enabled gradually, as it represents a significant behavior change that could impact production systems. Ensure this change is properly documented and communicated.

Suggested change

RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_RuntimeAsync, W("RuntimeAsync"), 1, "Enables runtime async method support")

RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_RuntimeAsync, W("RuntimeAsync"), 0, "Enables runtime async method support")

src/coreclr/jit/async.cpp

jakobbotsch · 2025-11-10T16:19:10Z

src/coreclr/jit/importer.cpp

-    // We cannot tailcall ValueTask returning methods as we need to preserve
-    // the Continuation instance for ValueTaskSource handling (the BCL needs
-    // to look at continuation.Next). We cannot easily differentiate between
-    // ValueTask and Task here, so we just disable it more generally.
-    if ((prefixFlags & PREFIX_IS_TASK_AWAIT) != 0)
-    {
-        return false;
-    }
-


This check is moved to the same place as the check for CORINFO_FLG_SYNCH, since it is similar in spirit (we need to introduce try-finally, so we cannot tailcall).

jakobbotsch · 2025-11-10T16:21:33Z

src/coreclr/jit/importercalls.cpp

-        asyncInfo.ExecutionContextHandling                  = ExecutionContextHandling::None;
-        asyncInfo.ContinuationContextHandling               = ContinuationContextHandling::None;
-        asyncInfo.SaveAndRestoreSynchronizationContextField = false;
    }


We could probably keep this for IL instantiating stubs, but since the case is rare this is probably ok.

AndyAyersMS

JIT changes LGTM, left some notes on (adding) comments.

AndyAyersMS · 2025-11-10T16:18:10Z

src/coreclr/jit/async.cpp

-                ValidateNoAsyncSavesNecessaryInStatement(stmt);
-                continue;
-            }
+    EHblkDsc* newEntry = nullptr;


You might want to call out that since this new EH region encloses all others it will be placed at the end of the EH table, so setting XTnew to the current table length is the correct thing to do.

AndyAyersMS · 2025-11-10T16:22:26Z

src/coreclr/jit/async.cpp

+    CORINFO_CALL_INFO callInfo = {};
+    callInfo.hMethod           = captureCall->gtCallMethHnd;
+    callInfo.methodFlags       = info.compCompHnd->getMethodAttribs(callInfo.hMethod);
+    impMarkInlineCandidate(captureCall, MAKE_METHODCONTEXT(callInfo.hMethod), false, &callInfo, compInlineContext);


Consider adding a stress mode even if CORINFO_ASYNC_SAVE_CONTEXTS is not set that runs the return merging logic anyways? Would require adding a stress mode arg to CreateReturnBB.

AndyAyersMS · 2025-11-10T16:24:37Z

src/coreclr/jit/async.cpp

+    {
+        newReturnBB->bbWeight = newReturnBB->computeIncomingWeight();
+    }
+


assert(fgReturnCount == 1)? (may be too annoying; I know sometimes we have trouble counting...)

AndyAyersMS · 2025-11-10T16:29:52Z

src/coreclr/jit/async.cpp

-            {
-                tree = tree->AsLclVarCommon()->Data();
-            }
+    // Create try-fault structure


Maybe mention that this is actually a try/finally but you're going to manually inline the finally and will only need one copy of it thanks to the return merging logic below.

VSadov · 2025-11-10T21:58:35Z

Do we still need context store/restore in task-returning thunks after this?

CC: @eduardo-vp

VSadov · 2025-11-10T22:44:49Z

src/coreclr/jit/importercalls.cpp

        canTailCall             = false;
        szCanTailCallFailReason = "Caller is Reverse P/Invoke";
    }
+    else if (compIsAsync())


Can non-variant/infrastructure helpers use tailcalls?

For the existing helpers, none of the calls that they contain would fit the tailcall pattern, so the question is mostly theoretical.

Yes, this check could be for CORINFO_ASYNC_SAVE_CONTEXTS instead. Instantiating stubs could maybe benefit.
It would require us to keep the other code I pointed at above (#121448 (comment))

VSadov · 2025-11-10T23:43:50Z

src/coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/AsyncHelpers.CoreCLR.cs


        [MethodImpl(MethodImplOptions.AggressiveInlining)]
-        private static void RestoreContexts(bool suspended, ExecutionContext? previousExecCtx, SynchronizationContext? previousSyncCtx)
+        private static void RestoreContexts(bool started, ExecutionContext? previousExecCtx, SynchronizationContext? previousSyncCtx)


maybe add a comment about meaning of "started". As I understand it is an indicator of whether we see a normal/initial entry into the method vs. we are resuming.
It was not obvious on the first read when I saw this method's changes.

jakobbotsch added 15 commits November 3, 2025 17:30

Initial plan

15f6e9e

Execute plan

8c6d04d

Fix bugs

dfd1ac5

Remove zeroing

7029384

Move earlier

fc6e12d

Merge branch 'main' of github.com:dotnet/runtime into save-restore-ar…

9039b7a

…ound-body

WIP

5b85955

One call to capture

9d1343f

Fix

9956a90

Fix

3ae0565

Merge branch 'main' of github.com:dotnet/runtime into save-restore-ar…

231f4f5

…ound-body

Delete

8a7d9e6

Run jit-format

41bd4ca

Disable testing

6aa6f06

Clean up

e78f8e8

jakobbotsch added the runtime-async label Nov 7, 2025

github-actions bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Nov 7, 2025

dotnet-policy-service bot assigned jakobbotsch Nov 7, 2025

Add test

3d81683

jakobbotsch marked this pull request as ready for review November 10, 2025 16:07

jakobbotsch requested review from AndyAyersMS, VSadov and Copilot November 10, 2025 16:07

jakobbotsch commented Nov 10, 2025

View reviewed changes

Copilot AI reviewed Nov 10, 2025

View reviewed changes

jakobbotsch commented Nov 10, 2025

View reviewed changes

AndyAyersMS reviewed Nov 10, 2025

View reviewed changes

build-analysis bot mentioned this pull request Nov 10, 2025

slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883

Open

3 tasks

VSadov mentioned this pull request Nov 10, 2025

Update EmitTaskReturningThunk in Native AOT #121435

Open

VSadov reviewed Nov 10, 2025

View reviewed changes

	// block - Block that contains the async calll
	// block - Block that contains the async call

	RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_RuntimeAsync, W("RuntimeAsync"), 1, "Enables runtime async method support")
	RETAIL_CONFIG_DWORD_INFO(UNSUPPORTED_RuntimeAsync, W("RuntimeAsync"), 0, "Enables runtime async method support")

JIT: Move Thread sync and exec context save/restore to happen around runtime async bodies #121448

Are you sure you want to change the base?

JIT: Move Thread sync and exec context save/restore to happen around runtime async bodies #121448

Conversation

jakobbotsch commented Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-service bot commented Nov 7, 2025

Uh oh!

jakobbotsch commented Nov 7, 2025

Uh oh!

davidwrighton commented Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jakobbotsch commented Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

davidwrighton commented Nov 8, 2025

Uh oh!

jakobbotsch commented Nov 8, 2025

Uh oh!

jakobbotsch commented Nov 10, 2025

Uh oh!

jakobbotsch Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VSadov Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Key Changes

Reviewed Changes

Uh oh!

Copilot AI Nov 10, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 10, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AndyAyersMS left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VSadov commented Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VSadov Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

jakobbotsch commented Nov 7, 2025 •

edited

Loading

davidwrighton commented Nov 7, 2025 •

edited

Loading

jakobbotsch commented Nov 7, 2025 •

edited

Loading

jakobbotsch Nov 10, 2025 •

edited

Loading

VSadov Nov 10, 2025 •

edited

Loading

VSadov commented Nov 10, 2025 •

edited

Loading

VSadov Nov 10, 2025 •

edited

Loading