RuntimeHelpers.PrepareDelegate/PrepareMethod should JIT the given method

[tmds]

There is a comment here:

https://github.com/dotnet/coreclr/blob/b9affb49f79ed8319923c2f5b07b4aeeb04efe36/src/mscorlib/src/System/Runtime/CompilerServices/RuntimeHelpers.cs#L147-L149

But I can't figure out if it is supported or not.

In case it isn't supported, is there another way to ensure certain methods in a call graph are jitted? Or to jit a method without calling it?

[jkotas]

PrepareConstrainedRegions is no-op in .NET Core.

[jkotas]

ensure certain methods in a call graph are jitted?

There is not such method today. I think it may be reasonable to fix RuntimeHelpers.PrepareDelegate / PrepareMethod to JIT the method given to it (just the single method - without the complicated limited call-graph walk done by full .NET Framework implementation).

[4creators]

I think it may be reasonable to fix RuntimeHelpers.PrepareDelegate / PrepareMethod to JIT the method given to it (just the single method

This could be very useful for hardware intrinsics in R2R scenarios.

[jkotas]

@4creators Could you please elaborate why you think it would be helpful?

[4creators]

@jkotas maybe we can move discussion on how to use it in hardware intrinsics to #9408 as it will fit the scope of that issue

[mattwarren]

I think it may be reasonable to fix RuntimeHelpers.PrepareDelegate / PrepareMethod to JIT the method given to it (just the single method - without the complicated limited call-graph walk done by full .NET Framework implementation).

Yes, this would be nice, based on this comment from @AndyAyersMS it currently has some limitations and the workaround is tricky.

Although I assume from your comment that you're not proposing to also JIT the entire call-graph, just a single method, is that correct?

Would PrepareMethod ever be extended to do this, i.e. ensure the entire call-graph of a method is also JITted, or is that not something you think the run-time should provide?

[jkotas]

the entire call-graph, just a single method, is that correct?

The problem is with finding the entire call-graph is. Static non-virtual calls are easy, but the transitive closure can be very large. In full .NET Framework, this method also consults ReliabilityContract attributes to constraint the call graph to reasonable size.

Virtual calls, generics and every other runtime feature are hard. It would basically have to do same kind of global analysis as full AOT compilation does (slow and complex).

We prefer to describe behavior in terms of what guarantees are provided. Not in terms of how the guarantees are implemented. The guarantees that the PrepareMethod provides in .NET Framework are that the runtime will not introduce exceptions in the part of the callgraph that is annotated as reliable (ie the only exceptions thrown during execution of the code are the ones caused by the user code). These guarantees have been implemented by JITing a bunch of stuff upfront and pre-initializing all sorts of other stuff that can lead to runtime-thrown exceptions. That implementation was not the only way to implement the guarantees.

This feature was originally implemented for SQL CLR. It was super hard to test and use correctly.

it currently has some limitations

This applies to .NET Framework.

My though above was that we can improve .NET Core compatibility for cases where folks take advantage of PrepareMethod side-effects in .NET Framework.

[tmds]

@jkotas I'm fine with this issue being closed or re-purposed to track support for PrepareMethod.

[tmds]

Thank you for implementing @jkotas!