Support for IL interpreter in CoreRT

[tonerdo]

We should consider porting Mono's .NET interpreter (http://www.mono-project.com/news/2017/11/13/mono-interpreter/) over to CoreRT, to support runtime IL generation and execution within native code

[jkotas]

The interpreter implementation is always tighly coupled with the underlying runtime implementation details. It cannot be easily ported from runtime to runtime. This would be more like a rewrite, maybe using some of the ideas from the other implementations. We would want to rewrite it in C# for CoreRT. Implementing it in C/C++ for CoreRT would be much harder than implementing it in C#.

BTW: We have interpreter in CoreCLR as well: https://github.com/dotnet/coreclr/blob/master/src/vm/interpreter.cpp . It is not shipping in .NET Core because of .NET Core would not benefit from it. It has been used for new platform bringups, and various experiments.

There are two distinct pieces:

• IL interpreter: The interpreter should not be tightly coupled with Reflection.Emit. It should be able to interpret any IL, e.g. even IL comming from regular IL .dlls. The idea is that we would have pluggable execution strategy for the IL. Some of the early plumbing for this has been done in our System.Private.Jit prototype - look for MethodExecutionStrategy. The interpreter can live in say System.Private.Interpreter and be pluged in as execution strategy. A good first step would be to put all scafolding in place that is able to interpret a super simple method that just returns "42" end-to-end. Let's use this issue to track further dicusssion on this.

• Refleflection.Emit: Reflection.Emit should be independent part as described in: https://github.com/dotnet/corefx/issues/4491#issuecomment-189756092 . Let's use this corefx issue for further discussion on Reflection.Emit. The "Run" flavor of Reflection.Emit should communicate with the runtime by passing PE files down. In case of DynamicMethods, it can pass down just baked IL method bodies as performance optimization since producing a PE file per dynamic method would be too expensive.

[tonerdo]

@jkotas looking to take a first pass at this. However, I have a couple of questions:

• The OnEntryPoint method returns an IntPtr which I'm guessing points to the native compiled code. How will this work in the context of the interpreter.
• Considering CoreRT ships without a JIT, at what point is the RyuJitExecutionStrategy used? Where in the code can I find it?

[jkotas]

The OnEntryPoint method returns an IntPtr

CoreRT has capability to manufacture entrypoints. Look for CallConverterThunk.MakeThunk for an example. The call converter is sort of a mini-interpreter that just changes once calling convention to a different one.

RyuJitExecutionStrategy

Code under src\System.Private.Jit was a prototype for JIT support in CoreRT. It was able to run a few methods, nothing extensive. It does not ship, and it is not used in the default CoreRT config and it has likely bit-rotten and does not work anymore.

[tonerdo]

Thanks for the quick response. I have more stuff I'm curious about

What happens when MethodInfo.Invoke(object, args) is called? I'm guessing there's a transition from managed code to unmanaged code at some point but I can't seem to find it (I've looked through coreclr, corefx and corert)

I ask because I'm trying my best to avoid using reflection and instead leverage the underlying runtime capabilities. Specifically how info like the value of static and instance fields are retrieved from a handle to a managed object (*Object?) that already exists in memory

[mattwarren]

What happens when MethodInfo.Invoke(object, args) is called? I'm guessing there's a transition from managed code to unmanaged code at some point but I can't seem to find it (I've looked through coreclr, corefx and corert)

I've written about this scenario, see the section on 'How does Reflection work?' (referring to the CoreCLR)

[tonerdo]

Sweet! thanks Matt! Will take a look.

[tonerdo]

Yup, that definitely answers my question, knew there had to be an FCALL somewhere

[mattwarren]

I've looked into the equivalent flow for CoreRT (mostly just for my own interest) and unless I'm missing something it's all in C#, which is pretty cool (I know that's one of the goals of CoreRT, it's just interesting to see it in action)!

• MethodInvoker - Object Invoke(..)
• MethodInvoker - protected abstract Object Invoke(..)
  • StaticMethodInvoker - override Object Invoke(..)
  • InstanceMethodInvoker - override Object Invoke(..)
  • VirtualMethodInvoker - override Object Invoke(..)
• RuntimeAugments - CallDynamicInvokeMethod(..)
• InvokeUtils - CallDynamicInvokeMethod(..)
• CalliIntrinsics - Call(..)

At this point there are no C# method bodies, but after a bit of digging, it seems that the [McgIntrinsics] attribute is a placeholder and the method bodies are wired up via ILProvider - CreateMethodIL(MethodDesc method) and finally CalliIntrinsic - EmitIL(MethodDesc target) (using OpCodes.Calli)

[tonerdo]

You should write a blog post on this 😃

[tonerdo]

Here's also for my second question on getting field info from an object reference:

• FieldAccessor - Object GetField(..)
• FieldAccessor - public abstract Object GetField(..)
  • StaticFieldAccessor - override Object GetField(..)
  • InstanceFieldAccessor - override Object GetField(..)
  • FieldAccessor List
• RuntimeAugments contains most of the code for interacting with the underlying runtime. Has methods for instantiation, getting/setting field values etc. Uses RuntimeImports under the hood, has exactly what I need

[morganbr]

It looks like you're on the right track with the implementation details in System.Private.Reflection.Execution (no FCALLs in CoreRT). @MichalStrehovsky or @davidwrighton, do you have any details to fill in?

[mattwarren]

Just out of interest, from reading this post there seems to be 2 possible approaches to allowing runtime code generation in CoreRT:

1. Implement an IL Interpreter
2. Use RyuJIT (i.e. System.Private.Jit)

I was wondering what's the preferred approach? Or in an ideal world would you have both? (leaving aside the cost to implement, engineering time, other priorities, etc)

Is 2) less preferable because it's no longer 'AOT compiled' or is that not really a concern? I assume that 1) is slower, but does that matter?