[draft] Improve startup and warmup performance for invoke by reducing emit usage

[steveharter]

[verifying tests]

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-reflection
See info in area-owners.md if you want to be subscribed.

[janvorli]

Can you please declare the variables at the assignment below? I think it is a preferred style in the coreclr runtime and it makes it easier to see the actual type the "new" allocates.

[janvorli]

@steveharter do you plan to add support for other well known signatures than the zero arg with return value and one arg with void return ones? Based on our past discussion, we would like to eventually add ones that are on startup path of common types of apps like e.g. aspnet ones. Or were these mostly just those two basic cases?

[steveharter]

@steveharter do you plan to add support for other well known signatures than the zero arg with return value and one arg with void return ones? Based on our past discussion, we would like to eventually add ones that are on startup path of common types of apps like e.g. aspnet ones. Or were these mostly just those two basic cases?

That approach (zero arg + one arg) was for property getters\setters however it didn't work for instance methods since function pointers don't support instance methods (sometimes it worked for simple methods, but other times it cause heap corruption) so I had to change it to very-hard-coded list of specific types and methods used during startup. That could be extended for other types based on the applications we want to check that are sensitive to startup\warmup (e.g. ASP.NET, WinForms)

However, that is somewhat untenable so we should really get function pointers to support instance methods, so I created the language proposal at dotnet/csharplang#8709. This would automatically bring in a ton of all methods, perhaps up to 50%, since it would cover most property getters and setters and other simple methods.

Another approach, compatible with the function pointer + instance methods above, is to add an API to let the application specify their own delegate for method that they do not want to cause emit\jit. E.g.:

public class MethodBase
{
    // We would support only our built-in delegates that are for property getters\setters, <= 4 args, byref args, etc.
+    void SetInvokeImplementation(Delegate delegate);
}
   

[jkotas]

function pointers to support instance methods,

We can emit the function-pointer based thunks for arbitrary instance methods as runtime intrinsics. We do not need first class C# support for instance method function pointers to make it work.