[clr-interp] Async Resume stubs are exclusive to the JIT as they use a set of intrinsics that are JIT specific

[davidwrighton]

• Disable running the interpreter compiler for these. In real scenarios we will either have a JIT to generate them, or they will be produced by the R2R compiler, so this should be a good long term solution

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR prevents the interpreter from attempting to compile async resume stubs, which use JIT-specific intrinsics that the interpreter cannot handle. The fix ensures that these stubs will be generated either by the JIT or R2R compiler.

• Adds a new IsAsyncResumeStub() method to check if a dynamic method is an async resume stub
• Updates the interpreter loading condition to skip async resume stubs

Reviewed changes

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

File	Description
src/coreclr/vm/method.hpp	Adds IsAsyncResumeStub() helper method to DynamicMethodDesc class, following the same pattern as other stub type checking methods
src/coreclr/vm/jitinterface.cpp	Modifies interpreter loading condition in UnsafeJitFunction to exclude async resume stubs from interpreter compilation

[janvorli]

I wonder if we should handle that in the interpreter compiler instead. I would expect the logic here to be agnostic of what interpreter compiler can and cannot generate.

[jkotas]

How do we get here in the first place? Why is the overridden implementation in CInterpreterJitInfo::getAsyncResumptionStub not enough?

[davidwrighton]

We get here when we're in one of the interpmodes that mixes jitting and interpreter compilation. So, we've got a jitted method which is async which is defined in System.Private.CoreLib.dll and then we need to compile the async resumption stub. Since handling of jit vs interpreter policy is decided in the interpreter codebase, and it doesn't know it can't compile these methods, it causes this failure. There are 3 alternative approaches.

1. Add handling for these intrinsics to the interpreter so that it can generate code for these helpers. Additionally we would probably benchmark that approach vs the current p/invoke approach and see if one approach or the other is faster.
2. Add a jit interface api that would allow the interpreter to skip support for these things.
3. Recognize the intrinsic in the interpreter and use that to trigger the interpreter to return CORJIT_SKIPPED. Arguably this is the cleanest implementation.

[janvorli]

The last option is what I was thinking.

[davidwrighton]

A closer analysis of this indicates that we already implement all of the needed intrinsics for this for other async thunk generated stubs (which has changed since I originally brought up async in the interpreter), so possibly we have a set of very hard to hit unboxing stub bugs in the interpreter... I'm going to take a closer look at if I should just fix the detail which is wrong here, and possibly add a new test for the paths which should have found issues on the current codebase, or at least understand better why this failed.

[davidwrighton]

Oops. It turns out that there is a specific intrinsic that needed to be implemented, and I'd implemented half of it. Finishing that out, made it all just work. @jakobbotsch did work to make the calling conventions here be entirely represented in the signature, just like it is for unboxing and other stubs, and it looks like it can now share logic with the normal jit path, so the interpreter can now generate this stub correctly. It ALSO happens that the interpreter codegen can't actually accept an incoming argument of a non-null so while we can now generate a functional stub here, we still can't use this path for interpreter resumption stubs. But we can have the interpreter resume one of the jitted methods.

The change is now materially different

[janvorli]

LGTM, thank you!