Unboxing+instantiating thunks

[MichalStrehovsky]

In native AOT we build instantiating+unboxing thunks that bridge the calling convention gap when calling instance methods on shared generic valuetypes virtually:

interface IFoo { void Method(); }

struct Gen<T> : IFoo
{
    // Native code for Gen<__Canon>.Method expects _reference_ to the first field of the struct as the first parameter,
    // and a "generic context" (that tells the __Canon method body what the T is) as the second parameter
    public void Method() => Console.WriteLine(typeof(T));
}

IFoo o = new Gen<string>();

// The callsite was set up as usual for interface method invocation so the first and only parameter
// is the `this` (`o` in this case)
o.Method();

We emit these as IL and use some tricks to make it compile (dotnet/corert#2566).

For runtime async, it looks like we're out of luck with this approach because we'd need to generate a method that is runtime async (doable) that calls another runtime async method while injecting the extra instantiation parameter and passing down async resume context too.

We'll probably need a RyuJIT feature.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[jakobbotsch]

For runtime async, it looks like we're out of luck with this approach because we'd need to generate a method that is runtime async (doable) that calls another runtime async method while injecting the extra instantiation parameter and passing down async resume context too.

We'll probably need a RyuJIT feature.

Can you explain further what makes this problematic?
Note that you don't need to pass the async continuation along. In fact that would be incorrect. We need to pass null for it.

Is it the fact that the JIT tries to insert its own async continuation for the async call? (In coreclr the hack is that calli with async calling convention is expected to already have async continuation passed. This case is the only async calli we have.)

[MichalStrehovsky]

Can you explain further what makes this problematic?
Note that you don't need to pass the async continuation along. In fact that would be incorrect. We need to pass null for it.

My concern is that we need to ensure rcx is not clobbered between the call to the entrypoint after unbox and the unboxing thunk return. Maybe it would be okay if we can call the entrypoint with a 100% guaranteed tailcall?

[jakobbotsch]

Can you explain further what makes this problematic?
Note that you don't need to pass the async continuation along. In fact that would be incorrect. We need to pass null for it.

My concern is that we need to ensure rcx is not clobbered between the call to the entrypoint after unbox and the unboxing thunk return. Maybe it would be okay if we can call the entrypoint with a 100% guaranteed tailcall?

It cannot be a 100% guaranteed tailcall since there is a different number of parameters in the two functions.
Also, rcx must be GC reported. So the JIT needs to be aware that GC ref was returned by the call in rcx.

What prevents the unboxing/instantiating IL stub from emitting a normal runtime async call? It is what coreclr does. It emits a calli with async calling convention. (The details for NAOT can be different if we can't emit as a calli.)

[MichalStrehovsky]

What prevents the unboxing/instantiating IL stub from emitting a normal runtime async call? It is what coreclr does. It emits a calli with async calling convention. (The details for NAOT can be different if we can't emit as a calli.)

We need to inject the generic context parameter. So generic context is a physical part of the IL signature that we give to RyuJIT so that we can populate it. If it's an async call, RyuJIT would need to inject continuation argument but it would end up in the wrong spot, no (generic context would look like a user argument to RyuJIT)?

[jakobbotsch]

If it's an async call, RyuJIT would need to inject continuation argument but it would end up in the wrong spot, no (generic context would look like a user argument to RyuJIT)?

Right. It is what I was alluding to in my first comment.
For coreclr, calli turns off the behavior:

runtime/src/coreclr/jit/importercalls.cpp

Lines 880 to 886 in 5eedc2a

	// Add async continuation arg. For calli these are used for IL
	// stubs and the VM inserts the arg itself.
	if (call->AsCall()->IsAsync() && (opcode != CEE_CALLI))
	{
	call->AsCall()->gtArgs.PushFront(this, NewCallArg::Primitive(gtNewNull(), TYP_REF)
	.WellKnown(WellKnownArg::AsyncContinuation));
	}

We can introduce a mechanism to explicitly turn off the behavior that they can use. Or switch to use intrinsics to explicitly set the generic context/async continuation. Or encode the generic context in the signature in a way that the JIT knows (like SwiftError).

[jkotas]

use intrinsics to explicitly set the generic context/async continuation

I think this would be the best option. It should work nicely for both CoreCLR/JIT and NAOT.

encode the generic context in the signature in a way that the JIT knows (like SwiftError).

It would work too, but it feels more complicated.

[jakobbotsch]

use intrinsics to explicitly set the generic context/async continuation

I think this would be the best option. It should work nicely for both CoreCLR/JIT and NAOT.

encode the generic context in the signature in a way that the JIT knows (like SwiftError).

It would work too, but it feels more complicated.

#121799 gets started on this

[VSadov]

I like the "use intrinsics to explicitly set the generic context/async continuation" because it pushes platform-specific dealing with signatures from VM into the JIT.