Use EcmaMethod as the async "impl" variant and create async "thunk" MethodDesc classes

[jtschuster]

Previously, AsyncMethodDesc was used to represent the Async variant of a method with IsAsync==true, regardless of what was in metadata. I think it makes more sense to use EcmaMethod to represent what is in metadata, and create two MethodDescs to represent the Async and Task-returning thunk variants.

• EcmaMethod represents the variant encoded in metadata, either async or Task-returning. The Signature is adjusted accordingly to align with the calling convention (Task/Task return becomes void/T, and AsyncCallConv flag is set).
• AsyncMethodDesc is replaced with AsyncMethodThunk, which is the Async variant thunk of a Task-returning implementation method.
• TaskReturningAsyncThunk is the variant of an async implementation method
• AsyncMethodData is a concept borrowed from the runtime implementation and was added to MethodDesc. For performance, it may make sense to move the Kind to MethodFlags and keep the async signature in a separate field, but I opted to keep it similar to the runtime.
• IsTaskReturning is now on MethodDesc and uses the AsyncMethodData to determine whether the type returns Task/ValueTask. It has different semantics than the runtime method of the same name, as this returns true for Async methods too.
• MethodSignature.ReturnsTaskOrValueTask() is added to determine if a method is AsyncMethodKind.TaskReturning.
• GetAsyncOtherVariant() is also borrowed from the runtime implementation. This makes the AsyncMethodDescFactory unnecessary, as the single "other variant" can be retrieved from each impl variant without creating a new instance each time. This is implemented on EcmaMethod and all Instantiated methods, as well as the new AsyncMethodThunk and TaskReturningAsyncThunk.

[Copilot]

Pull Request Overview

This PR refactors the async method handling infrastructure in the CoreCLR AOT compiler's type system. It moves async method variant management from the JIT interface layer into the core type system, making async method thunks first-class citizens with proper lifetimes.

Key changes:

• Moved async method thunk creation from JitInterface to the core type system with new AsyncMethodThunk and TaskReturningAsyncThunk classes
• Introduced AsyncMethodData and AsyncMethodKind to track method async characteristics and signatures
• Updated EcmaMethod, MethodForInstantiatedType, and InstantiatedMethod to support async variant tracking

Reviewed Changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
ILCompiler.TypeSystem.csproj	Adds new async thunk source files to the project
ILCompiler.ReadyToRun.csproj	Removes old JitInterface async method files
EcmaMethod.cs	Adds async method data tracking and variant generation, reformats constants
TaskReturningAsyncThunk.cs	New thunk class for async-callable variants of Task-returning methods
MethodForInstantiatedType.cs	Adds async variant support for instantiated type methods
MethodDesc.cs	Adds core async infrastructure: ReturnsTaskOrValueTask(), CreateAsyncSignature(), AsyncMethodData, AsyncMethodKind, GetAsyncOtherVariant()
MethodDelegator.cs	Makes AsyncMethodData abstract for delegator implementations
InstantiatedMethod.cs	Adds async variant support for generic method instantiations
AsyncMethodThunk.cs	New thunk class for async variants of Task-returning methods
AsyncMethodDescFactory.cs	Deleted - factory no longer needed with new approach
AsyncMethodDesc.cs	Deleted - replaced by new thunk classes in type system

[Copilot]

Pull Request Overview

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

[Copilot]

Pull Request Overview

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

[Copilot]

Missing using System.Threading; directive. The code uses Interlocked.CompareExchange on line 46 but doesn't import the System.Threading namespace. While the main InstantiatedMethod.cs file has this import, partial class files need their own using directives for the types they reference.

Suggested change

	using System.Diagnostics;
	using System.Diagnostics;
	using System.Threading;

[MichalStrehovsky]

What considerations lead to turning EcmaMethod into the "impl" variant of async? I understand there are going to be warts no matter how we implement this, but on the surface EcmaMethod not having the signature that it has in the metadata will lead to a lot of warts. My instinct would be to keep the signature as-is.

This is not the first time we're in a situation where a single method can have different entrypoints with different signature. We have similar situation with unboxing thunks (R2R + NAOT), instantiating thunks (R2R), special default interface method instantiating thunks (NAOT), or even p/invokes (NAOT, distinguishing the marshalled and "naked" entrypoints),

In the CoreCLR type system the distinction between "entry point" and "method" is kind of fuzzy (even before async) - it's all kinds of MethodDescs.

In our managed compilers, we represent entry points using ISymbolNode - often actual code bytes that one can refer to with a reloc. Methods are represented with MethodDescs. Typically there's just one MethodDesc for a single method (modulo generics). Sometimes we make more than one MethodDesc for a single method, but those are always short lived and don't leak out from the component that knows how to handle it (like the MethodDesc that is getting deleted in this PR). We don't want to end up with these "weird" MethodDescs in parts of the system that shouldn't have to deal with the weirdness.

For example, with unboxing thunks, most of the system doesn't care about their existence. Some parts of the system deal with them by carrying a pair of MethodDesc + bool. And we have a MethodDesc for them that is local to the JitInterface but doesn't enter the rest of the compiler.

In native AOT, there's also an instantiating unboxing MethodDesc that is similar to how I think of async so far:

runtime/src/coreclr/tools/aot/ILCompiler.RyuJit/Compiler/DependencyAnalysis/RyuJitNodeFactory.cs

Lines 23 to 30 in 9ebda3d

	if (TypeSystemContext.IsSpecialUnboxingThunkTargetMethod(method))
	{
	return MethodEntrypoint(TypeSystemContext.GetRealSpecialUnboxingThunkTargetMethod(method));
	}
	else if (TypeSystemContext.IsDefaultInterfaceMethodImplementationThunkTargetMethod(method))
	{
	return MethodEntrypoint(TypeSystemContext.GetRealDefaultInterfaceMethodImplementationThunkTargetMethod(method));
	}

This one also exists, but its existence is pretty limited because very few components will get to the MethodDesc itself (we basically only hand it out to RyuJIT).

It was added in dotnet/corert#2566 and the implementation is still pretty much the same.

---

The runtime async methods look like normal method when looking at them in IL. The callsites to them look regular. They are weird when one looks at the method body. So my instinct would be not to make EcmaMethod for these methods weird right off the bat. Most components will probably not care about handling these specially. If we make the signature on EcmaMethod weird, suddenly a lot of components that don't really need to deal with async will have to deal with async. For example:

Resolving a MemberRef that was created before runtime async into a definition that is runtime async will need special casing in signature comparisons:

runtime/src/coreclr/tools/Common/TypeSystem/Ecma/EcmaType.cs

Lines 321 to 336 in 9ebda3d

	public override EcmaMethod GetMethod(ReadOnlySpan<byte> name, MethodSignature signature, Instantiation substitution)
	{
	var metadataReader = this.MetadataReader;
	foreach (var handle in _typeDefinition.GetMethods())
	{
	if (metadataReader.StringEquals(metadataReader.GetMethodDefinition(handle).Name, name))
	{
	var method = _module.GetMethod(handle, this);
	if (signature == null || signature.Equals(method.Signature.ApplySubstitution(substitution)))
	return method;
	}
	}
	return null;
	}

Reflection metadata generation will need to undo the async transform:

runtime/src/coreclr/tools/aot/ILCompiler.MetadataTransform/ILCompiler/Metadata/Transform.Method.cs

Lines 159 to 178 in 9ebda3d

	public override MethodSignature HandleMethodSignature(Cts.MethodSignature signature)
	{
	// TODO: if Cts.MethodSignature implements Equals/GetHashCode, we could enable pooling here.
	var result = new MethodSignature
	{
	CallingConvention = GetSignatureCallingConvention(signature),
	GenericParameterCount = signature.GenericParameterCount,
	ReturnType = HandleType(signature.ReturnType),
	// TODO-NICE: VarArgParameters
	};
	result.Parameters.Capacity = signature.Length;
	for (int i = 0; i < signature.Length; i++)
	{
	result.Parameters.Add(HandleType(signature[i]));
	}
	return result;
	}

We'll need to special case async in virtual method resolution. Etc.

My initial instinct would be to leave the metadata as it is in the IL file and make very local MethodDescs as needed. And extra flags where needed:

runtime/src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRunCodegenNodeFactory.cs

Line 964 in 9ebda3d

public DynamicHelperCellKey(MethodWithToken method, bool isUnboxingStub, bool isInstantiatingStub)

[jkotas]

I agree with @MichalStrehovsky . This should stay as is.

[jkotas]

The managed type system "features" have been designed as incremental. E.g. adding *CodeGen* or *Sorting* does not change how any of the core methods work. This change would be violating this design.