.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

.NET 10

Code complete:

• 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] Implement ilasm/ildasm support for the MethodImpl.Async #115093
• [RuntimeAsync] Disallow introduction of captured byrefs in strength reduction #115260
• [RuntimeAsync] Double check OSR in async2 struct instance methods #115259
• [RuntimeAsync] Reflection complains about ambiguity when querying async2 methods #115258
• Enable runtime-async ifdef in main
  • All Pri0 coreclr tests pass with ifdef enabled
  • All Pri1 coreclr tests pass with ifdef enabled
  • All libraries tests pass with ifdef enabled
  • Compiler changes are available in production compiler, behind preview flag
  • [RuntimeAsync] Reflection/introspection support #115099
  • [RuntimeAsync] Multicore JIT support. #115097
  • [RuntimeAsync] Implement new byref local zeroing #115262
  • [RuntimeAsync] Avoid keeping continuation state alive after resumption #115263
  • [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

Design issues:

• 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))
• What are restrictions and guarantees for runtime async methods in structs.
• What, if any, are the stack requirements on calling a method with the async calling convention inside an async method?
• What do we do for async delegates in general and Func<T> in particular?
• What to do with Event and Property accessors. Presumably they cannot be async, so what happens if return Task and Async marker is applied?

.NET 11

• [RuntimeAsync] PGO support. #115096
• [RuntimeAsync] R2R support #115098
• [RuntimeAsync] Dynamic methods (System.Reflection.Emit). #115101
• What do we do for function pointers to async methods?

[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