.NET Runtime-Async Feature

[agocke]

Intro

This issue tracks progress on implementing so-called "runtime-async", meaning implementation for async methods directly inside the .NET runtime. This is in contrast to the current support which is implemented only in language compilers, like C#, VB, and F#.

Draft specification: https://github.com/dotnet/runtime/blob/main/docs/design/specs/runtime-async.md

Design issues to be resolved:

• Are we going to use an attribute of a MethodImpl flag to identify async methods?
  (Re comment:Add draft of runtime async ECMA-335 changes #104063 (comment))
  • Resolved: Yes.
• What are restrictions and guarantees for runtime async methods in structs.
  • Resolved: By-refs are not preserved across Awaits, so the compiler is responsible for making sure that struct instance methods don't occur across Await
• What, if any, are the stack requirements on calling a method with the async calling convention inside an async method?
  • Resolved: The stated return type of an async method is the Task-like type. The stack should instead hold the type argument type (or nothing).
• What do we do for async delegates in general and Func<T> in particular?
  • The helpers will work fine, but the call may be slower than not going through delegates.
• What do we do for function pointers to async methods?
• What to do with Event and Property accessors. Presumably they cannot be async, so what happens if return Task and Async marker is applied?
  • Resolved: No special restriction at the runtime level.

Work

• Merge runtime into runtime-labs for integration
• Merge from runtime-labs into runtime
• Bring up testing in dotnet/runtime
  • Bring over Roslyn package for testing
• [RuntimeAsync] PGO support. #115096
• [RuntimeAsync] R2R support #115098
• [RuntimeAsync] Reflection/introspection support #115099
• [RuntimeAsync] Multicore JIT support. #115097
• [RuntimeAsync] Dynamic methods (System.Reflection.Emit). #115101
• [RuntimeAsync] Implement new byref local zeroing #115262
• [RuntimeAsync] Implement ilasm/ildasm support for the MethodImpl.Async #115093
• [RuntimeAsync] Avoid keeping continuation state alive after resumption #115263
• [RuntimeAsync] Disallow introduction of captured byrefs in strength reduction #115260
• [RuntimeAsync] Implement suspension-aware liveness and dead-code elimination #115261
• [RuntimeAsync] Remove JitOptimizeAwait knob (or make checked), eventually. #115264
• [RuntimeAsync] Revisit TODOs in places of questionable intersections of existing scenarios and Async #115094
• [RuntimeAsync] Double check OSR in async2 struct instance methods #115259
• [RuntimeAsync] Reflection complains about ambiguity when querying async2 methods #115258

[dotnet-policy-service]

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

[jakobbotsch]

What, if any, are the stack requirements on calling a method with the async calling convention inside an async method?

From RyuJIT's perspective restrictions will not make things simpler -- i.e. having the stack non-empty is fine. Of course these values are subject to same restrictions as locals live across suspension points.

What do we do for async delegates in general and Func in particular?
What do we do for function pointers to async methods?

I think without introducing an explicit async calling convention in the signature the only option is to let them point to the runtime synthesized Task<T> returning version of the method. It means taking the address of a runtime-async function is illegal in IL (when doing this in C# the compiler would instead generate IL taking the address of the Task/Task<T> returning version).

From RyuJIT's perspective I think this can still be optimizable via PGO and delegate GDV in the "runtime-async calling delegate that ends up in runtime-async" case. Roslyn will generate the "runtime-async calling compiler-async" IL, but I think we can recognize this and optimize it to "runtime-async calling runtime-async" when GDV kicks in.

Having an explicit async calling convention would be a way for the user to ensure that this optimization kicks in. The UnmanagedCallersOnly and delegate* unmanaged work laid a pretty extensible framework for doing this sort of thing, so maybe it wouldn't be too expensive to build that support for function pointers. For delegates I'm not so sure, seems like we would end up with AsyncAction and AsyncFunc there to encode the async calling convention.

[julealgon]

@agocke can you provide a bit more context to this? I assume there is a broader discussion and that this issue here is just kind of a "summary" of sorts.

Is the idea to move away from "compiler-generated" async state machine and have the runtime recognize the actual pattern as a first-class thing?

[KeterSCP]

@julealgon see #94620

[333fred]

What do we do for async delegates in general and Func in particular?

Related is are also methods like the following:

• T M<T>(), when called as await M<Task>()
• Task<T> M<T>() when called as await M<int>()
  • In particular, are these methods runtime-async capable? If so, what's the signature?

[agocke]

@333fred I think those two questions are answered in the spec. There's a note at the bottom:

[Note: these rules operate before generic substitution, meaning that a method which only meets requirements after substitution would not be considered as valid.]

So your example (1) is invalid -- that method is not async.
Your example (2) is fine -- that method is async. The unwrapping signature is modreq(Task<T>) T M<T>()

[agocke]

@julealgon Also see #104063