Move async variant resolution into `getCallInfo` by jakobbotsch · Pull Request #124550 · dotnet/runtime

jakobbotsch · 2026-02-18T13:39:49Z

Remove await CORINFO_TOKENKINDs
Add CORINFO_CALLINFO_ALLOWASYNCVARIANT flag and pass this for getCallInfo
Teach getCallInfo to resolve async variants
Reorder some code in getCallInfo so that we can know if an await is direct or not at the time where we resolve async variants

Another benefit is that we now automatically take IsEffectivelySealed into account in NAOT.

dotnet-policy-service · 2026-02-18T13:40:55Z

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

Copilot

Pull request overview

This pull request refactors async variant resolution by moving it from resolveToken into getCallInfo. This change fixes issue #124545 where static virtual calls were incorrectly going through task-returning thunks instead of calling the async implementation directly.

Changes:

Removes CORINFO_TOKENKIND_Await and CORINFO_TOKENKIND_AwaitVirtual token kinds from the JIT/EE interface
Adds CORINFO_CALLINFO_ALLOWASYNCVARIANT flag to request async variant resolution during getCallInfo
Moves async variant resolution logic from token resolution to call info resolution, ensuring it happens after direct call determination
Updates JIT code to pass the new flag when async patterns are detected
Replaces the combine helper function with proper C++ operators for flag manipulation

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/coreclr/inc/corinfo.h	Removes Await token kinds, adds ALLOWASYNCVARIANT flag, adds resolvedAsyncVariant field to CORINFO_CALL_INFO
src/coreclr/inc/jiteeversionguid.h	Updates JIT/EE interface GUID for the interface change
src/coreclr/vm/jitinterface.cpp	Removes async variant resolution from resolveToken, adds it to getCallInfo after directCall determination
src/coreclr/jit/importer.cpp	Updates call import logic to use new flag instead of special token kinds
src/coreclr/jit/importercalls.cpp	Removes obsolete comment about CEE_CALLI async handling
src/coreclr/jit/morph.cpp	Updates flag combining to use new operators
src/coreclr/jit/ee_il_dll.hpp	Replaces combine function with proper C++ operators for CORINFO_CALLINFO_FLAGS

src/coreclr/inc/corinfo.h

src/coreclr/vm/jitinterface.cpp

jakobbotsch · 2026-02-18T15:04:56Z

src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

+        private MethodDesc GetRuntimeDeterminedMethodForTokenWithTemplate(ref CORINFO_RESOLVED_TOKEN pResolvedToken, MethodDesc templateMethod)
+        {
+            object result = GetRuntimeDeterminedObjectForToken(ref pResolvedToken);
+            Debug.Assert(result is MethodDesc);
+
+            if (templateMethod.IsAsyncVariant() && !((MethodDesc)result).IsAsyncVariant())
+            {
+                result = _compilation.TypeSystemContext.GetAsyncVariantMethod((MethodDesc)result);
+            }
+
+            return (MethodDesc)result;
+        }


Not so sure about this. I am open to suggestions of alternatives. This is the replacement of the CorInfoTokenKind.CORINFO_TOKENKIND_Await that used to be in GetRuntimeDeterminedObjectForToken.

How about private object GetRuntimeDeterminedObjectForToken(ref CORINFO_RESOLVED_TOKEN pResolvedToken, bool isAsyncVariant = false) (add optional parameter to the existing method)?

The value of the bool is easy to pass in getCallInfo (we can just remember it) and elsewhere we populate it from whatever was considered the template.

Implemented that. Can you take another look?

Copilot

Pull request overview

Copilot reviewed 13 out of 13 changed files in this pull request and generated 1 comment.

Copilot · 2026-02-18T15:19:48Z

src/coreclr/vm/jitinterface.cpp

+    if ((flags & CORINFO_CALLINFO_ALLOWASYNCVARIANT) && pMD->ReturnsTaskOrValueTask())
+    {
+        if (!directCall || pTargetMD->IsAsyncThunkMethod())
+        {
+            // Either a virtual call or a direct call where the async variant


getCallInfo now resolves async variants when CORINFO_CALLINFO_ALLOWASYNCVARIANT is set, but (unlike the NativeAOT implementation) it doesn’t exclude delegate types. For Delegate.Invoke calls, resolving to an async variant can defeat the existing wrapperDelegateInvoke fast-path and may introduce unnecessary thunking. Consider adding a guard like !pMD->GetMethodTable()->IsDelegate() (or equivalent) before calling GetAsyncVariant.

jakobbotsch · 2026-02-18T15:33:51Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2026-02-18T15:34:01Z

Azure Pipelines successfully started running 1 pipeline(s).

jakobbotsch · 2026-02-18T20:54:12Z

Green CI including nativeaot-outerloop! But crossgen2 handling is missing so will push that.

Copilot

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.

MichalStrehovsky

The managed part LGTM otherwise!

MichalStrehovsky · 2026-02-19T13:22:26Z

src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

                result = ((TypeDesc)result).MakeArrayType();
-
-            if (pResolvedToken.tokenType is CorInfoTokenKind.CORINFO_TOKENKIND_Await or CorInfoTokenKind.CORINFO_TOKENKIND_AwaitVirtual)
+            if (isAsyncVariant && !((MethodDesc)result).IsAsyncVariant())


Is this part necessary?

Suggested change

if (isAsyncVariant && !((MethodDesc)result).IsAsyncVariant())

if (isAsyncVariant)

Yes, it is needed since the token may represent async variants directly for internal compiler-generated IL (like the thunks), so the result may already be the async variant for those cases. GetAsyncVariant asserts since they aren't task-returning in those cases.
(We won't hit that from the getCallInfo callers, but we can hit it from uses in other functions)

jakobbotsch · 2026-02-19T13:45:59Z

src/coreclr/jit/importercalls.cpp

-    else if (opcode == CEE_CALLI)
-    {
-        // Used for unboxing/instantiating stubs
-        JITDUMP("Call is an async calli\n");
-    }


Unrelated cleanup, this is no longer needed.

jakobbotsch · 2026-02-19T22:23:09Z

I think @VSadov is OOF. @jkotas can you take a look at the VM bits?
@davidwrighton can you take a look at the interpreter part? Also, do the async tests run with interpreter in CI or how do I test that?
cc @EgorBo for the JIT parts.

EgorBo

JIT lgtm

jkotas · 2026-02-19T22:32:20Z

src/coreclr/inc/corinfo.h

+    // async variant or NULL if no async variant was resolved.
+    // This is the async variant of the token's method and differs from hMethod
+    // of this class in cases of sharing, constrained resolution etc.
+    CORINFO_METHOD_HANDLE   resolvedAsyncVariant;


Why is this a separate CORINFO_METHOD_HANDLE field and not just returned in hMethod?

The idea with getCallInfo is that it tells the JIT what to call exactly. I assume that if the VM tells the JIT to call async variant, the JIT is better to call it. Is that correct?

hMethod does return the async variant of the target method, and that's what the JIT calls, but that differs from the async variant of the token's method in cases of sharing or due to constrained calls. The JIT takes this CORINFO_METHOD_HANDLE and updates hMethod of the token with it since the token itself is passed back into the EE in various cases. That makes token match what was happening before when it was part of resolveToken (specifically so that the EE sees the same hMethod in that token).

I am not 100% sure what the EE sides end up using hMethod of the token for in those callbacks and whether this could be simplified or not.

I suppose the primary one is that we call embedGenericHandle and pass it the token to compute the runtime lookup for an instantiation parameter, here:

runtime/src/coreclr/jit/importercalls.cpp

Lines 805 to 810 in 4eebedb

instParam = impTokenToHandle(pResolvedToken, &runtimeLookup, true /*mustRestoreHandle*/);

if (instParam == nullptr)

{

assert(compDonotInline());

return TYP_UNDEF;

}

This works now because the JIT updates the token's hMethod with callInfo.resolvedAsyncVariant when it notices that the async variant was resolved.

Perhaps a cleaner way would be if getCallInfo directly returned the runtime lookup instead of this embed roundtrip. The current token vs callInfo.hMethod mismatch leads to other problems here, I guess this comment is referencing the same thing:

runtime/src/coreclr/vm/jitinterface.cpp

Lines 5252 to 5269 in 4eebedb

// If the target method is resolved via constrained static virtual dispatch

// And it requires an instParam, we do not have the generic dictionary infrastructure

// to load the correct generic context arg via EmbedGenericHandle.

// Instead, force the call to go down the CORINFO_CALL_CODE_POINTER code path

// which should have somewhat inferior performance. This should only actually happen in the case

// of shared generic code calling a shared generic implementation method, which should be rare.

//

// An alternative design would be to add a new generic dictionary entry kind to hold the MethodDesc

// of the constrained target instead, and use that in some circumstances; however, implementation of

// that design requires refactoring variuos parts of the JIT interface as well as

// TryResolveConstraintMethodApprox. In particular we would need to be abled to embed a constrained lookup

// via EmbedGenericHandle, as well as decide in TryResolveConstraintMethodApprox if the call can be made

// via a single use of CORINFO_CALL_CODE_POINTER, or would be better done with a CORINFO_CALL + embedded

// constrained generic handle, or if there is a case where we would want to use both a CORINFO_CALL and

// embedded constrained generic handle. Given the current expected high performance use case of this feature

// which is generic numerics which will always resolve to exact valuetypes, it is not expected that

// the complexity involved would be worth the risk. Other scenarios are not expected to be as performance

// sensitive.

How about we introduce CORINFO_TOKENKIND_Async, then delete CORINFO_METHOD_HANDLE resolvedAsyncVariant;, and keep using hMethod, but also set the async tokenType on the EE side whenever we return the async variant.

That way we'll keep clearly marking the token as "async variant token". It is weird that the EE side would change tokenType, but also JIT side changing hMethod is not exactly clean.

It would work but it will be a new contract for getCallInfo (now has another output, requires SPMI changes).

It's probably a bit better but I am leaning towards making it so that we do not need the token anymore for non-trivial things after getCallInfo has been called by making it return the runtime lookup. It seems it is the only way to make things self-consistent.

jakobbotsch added 2 commits February 18, 2026 14:37

Move async variant resolution into getCallInfo

a2713ef

Update JIT-EE GUID

5164966

Copilot AI review requested due to automatic review settings February 18, 2026 13:39

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

dotnet-policy-service bot assigned jakobbotsch Feb 18, 2026

Copilot started reviewing on behalf of jakobbotsch February 18, 2026 13:41 View session

Copilot AI reviewed Feb 18, 2026

View reviewed changes

src/coreclr/inc/corinfo.h Show resolved Hide resolved

src/coreclr/vm/jitinterface.cpp Outdated Show resolved Hide resolved

jakobbotsch added 4 commits February 18, 2026 15:12

Fix build

1d0de49

Implement in ilc

c85622b

Fix when tokens refer directly to async variants

f9224d4

Update ILScanner

eb135f9

Copilot AI review requested due to automatic review settings February 18, 2026 15:01

jakobbotsch commented Feb 18, 2026

View reviewed changes

Copilot started reviewing on behalf of jakobbotsch February 18, 2026 15:05 View session

Copilot AI reviewed Feb 18, 2026

View reviewed changes

Update crossgen2 getCallInfo too

29ba4aa

This was referenced Feb 19, 2026

Test failure: baseservices/exceptions/stackoverflow/stackoverflowtester/stackoverflowtester.cmd #110173

Open

[android][clr] No peer certificates when executing System.Net.Http.Functional.Tests on Android emulator #124526

Open

jakobbotsch marked this pull request as ready for review February 19, 2026 01:41

jakobbotsch requested review from BrzVlad and MichalStrehovsky as code owners February 19, 2026 01:41

Copilot AI review requested due to automatic review settings February 19, 2026 01:41

jakobbotsch requested review from janvorli and kg as code owners February 19, 2026 01:41

jakobbotsch requested review from VSadov and jkotas February 19, 2026 01:41

Copilot started reviewing on behalf of jakobbotsch February 19, 2026 01:42 View session

Copilot AI reviewed Feb 19, 2026

View reviewed changes

Feedback

88be40f

MichalStrehovsky reviewed Feb 19, 2026

View reviewed changes

jakobbotsch commented Feb 19, 2026

View reviewed changes

This was referenced Feb 19, 2026

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

[android-arm64] The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#6408

Open

jakobbotsch requested review from EgorBo and davidwrighton February 19, 2026 22:23

EgorBo approved these changes Feb 19, 2026

View reviewed changes

jkotas reviewed Feb 19, 2026

View reviewed changes

	if (isAsyncVariant && !((MethodDesc)result).IsAsyncVariant())
	if (isAsyncVariant)

	instParam = impTokenToHandle(pResolvedToken, &runtimeLookup, true /mustRestoreHandle/);
	if (instParam == nullptr)
	{
	assert(compDonotInline());
	return TYP_UNDEF;
	}

	// If the target method is resolved via constrained static virtual dispatch
	// And it requires an instParam, we do not have the generic dictionary infrastructure
	// to load the correct generic context arg via EmbedGenericHandle.
	// Instead, force the call to go down the CORINFO_CALL_CODE_POINTER code path
	// which should have somewhat inferior performance. This should only actually happen in the case
	// of shared generic code calling a shared generic implementation method, which should be rare.
	//
	// An alternative design would be to add a new generic dictionary entry kind to hold the MethodDesc
	// of the constrained target instead, and use that in some circumstances; however, implementation of
	// that design requires refactoring variuos parts of the JIT interface as well as
	// TryResolveConstraintMethodApprox. In particular we would need to be abled to embed a constrained lookup
	// via EmbedGenericHandle, as well as decide in TryResolveConstraintMethodApprox if the call can be made
	// via a single use of CORINFO_CALL_CODE_POINTER, or would be better done with a CORINFO_CALL + embedded
	// constrained generic handle, or if there is a case where we would want to use both a CORINFO_CALL and
	// embedded constrained generic handle. Given the current expected high performance use case of this feature
	// which is generic numerics which will always resolve to exact valuetypes, it is not expected that
	// the complexity involved would be worth the risk. Other scenarios are not expected to be as performance
	// sensitive.

Conversation

jakobbotsch commented Feb 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-service bot commented Feb 18, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

jakobbotsch Feb 18, 2026 • 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

Uh oh!

Copilot AI Feb 18, 2026

Choose a reason for hiding this comment

Uh oh!

jakobbotsch commented Feb 18, 2026

Uh oh!

azure-pipelines bot commented Feb 18, 2026

Uh oh!

jakobbotsch commented Feb 18, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

MichalStrehovsky 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!

jakobbotsch commented Feb 19, 2026

Uh oh!

EgorBo left a comment

Choose a reason for hiding this comment

Uh oh!

jkotas Feb 19, 2026 • 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!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Comments

jakobbotsch commented Feb 18, 2026 •

edited

Loading

jakobbotsch Feb 18, 2026 •

edited

Loading

jkotas Feb 19, 2026 •

edited

Loading