[RuntimeAsync] R2R and Native AOT support

[VSadov]

• Update managed type system to understand MethodImpl.Async Pass async flag to jit in aot tools #120772
• Create MethodDescs for async thunks (Async version of Task-returning, Task-returning version of Async)
• Determine the best format for emitting async variants and resumption stubs into an R2R image. Emitting Async methods in ReadyToRun image #121559
• Update R2R dump to indicate the async thunks and any other information that is helpful.
• Get a totally sync Async method compiling and running.
• Get a method with an await compiling and running.
• Generate IL for the Async thunks that forward to Task-returning methods.
• Generate IL for the Task-returning thunks that forward to Async methods.
• Enable R2R for Async helpers. We explicitly make them BypassReadyToRun. This could be done today, they will just fail r2r compilation and not be emitted into the image.
• Emit the AsyncResumptionStubs to the readytorun image. These likely will go into the InstantiatedMethodEntryPointTable with a new flag for ResumptionStubs.
• Retrieve the AsyncResumptionStubs from the image at runtime.
• Determine behavior expected for a generic method that returns T when instantiated with T as Task.

Some relevant source files:
src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs
src/coreclr/tools/Common/TypeSystem/Common/AsyncMethodDesc.cs
src/coreclr/tools/Common/TypeSystem/Common/MethodDelegator.cs
src/coreclr/tools/Common/TypeSystem/Common/MethodDesc.cs
src/coreclr/tools/Common/TypeSystem/Ecma/EcmaMethod.cs
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/InstanceEntryPointTableNode.cs
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunTableManager.cs
src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IL/ReadyToRunILProvider.cs
src/coreclr/vm/readytoruninfo.cpp
src/coreclr/vm/readytoruninfo.h

[dotnet-policy-service]

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

[VSadov]

One easy way to start is to make the managed type system familiar with IsAsync methods in IL. Recognizing that will be needed anyways.

IL emitter (i.e. Roslyn) marks new-style async methods with MethodImpl.Async, but right now only the native typesystem knows that it has a certain meaning.

[VSadov]

An interesting side-quest could be making ILSpy recognize async methods as well. Not sure if ILSpy uses the same type system or something related/similar.

Inside IsAsync method the body returns a value of an "unwarapped" formal return type. That is - if the formal type is a Task/ValueTask/Task<T>/ValueTask<T>, we expect the body to return an unwrapped value. No need to warn on ret instruction about return type mismatches, or underflows in a case of unwrapped type is void.

Also AsyncHelpers.Await(something) could be decompiled into await something

[VSadov]

There are three kinds of methods that are dynamically generated by VM for async:

• A non-async Task-returning stub for async methods.
• An async stub for non-async Task-returning methods.

The above two are generated in src\coreclr\vm\asyncthunks.cpp
Every Task-returning method will have a parallel stub like above. Whether it is one or another depends on whether the method in IL is MethodImpl.Async or ordinary Task-returning.

I would look at features like unboxing stubs for something preexisting that could have some similarity.

• A Resume stub that is used to resume an async method when continuation is resumed.

Look at getAsyncResumptionStub in src\coreclr\vm\jitinterface.cpp
In the current codegen strategy every async method that has reachable awaits will need a resume stub and there is API by which JIT can ask for a Resume stub.

I assume in AOT case the above will be generated statically.