dotnet / corert

I'm interesting in assembly loading functional Assembly.LoadFile(). How it can implemented and will it be implemented? I see two ways how to do it:

First option is using interpreter #5011 (as I see @tonerdo has huge progress)
Second is using Native Library mode (https://github.com/dotnet/corert/tree/master/samples/NativeLibrary). Libraries can be precopiled an loaded (like dlopen). Can it work?

cc @jkotas @kvochko @iarischenko @kbaladurin

First option is using interpreter

Interpreter (https://github.com/dotnet/corert/tree/master/src/System.Private.Interpreter/src) or JIT (https://github.com/dotnet/corert/tree/master/src/System.Private.Jit/src). They have different performance characteristics, but otherwise pretty equivalent.

Native Library mode

Loading libraries compiled in native library mode is not really Assembly.LoadFile equivalent. The native library can communicate with the rest of the world using native exported entrypoint only. You would not be able to seamlesly exchange objects between the program and the native library - each of them would have its own copy of System.Object, etc.

Oh, I see...
What is the status of Interpreter and JIT? It looks interpreter has a lot of unimplemented instructions, e.g. work with objects.
Also if we try using Interpreter or JIT and load library which call some API from CoreFX, where it will take these classes?

Interpreter and JIT

Both are early prototypes. A lot of work to finish.

if we try using Interpreter or JIT and load library which call some API from CoreFX, where it will take these classes?

You can either full AOT compile the whole CoreFX (very big binary), or you can use partial AOT scheme like what CoreCLR does and fill in the missing methods using interpreter or JIT.

or you can use partial AOT scheme like what CoreCLR does and fill in the missing methods using interpreter or JIT

An in this case we have to keep all system DLL, right?

Right. It becomes very much like what CoreCLR looks today.

@jkotas could you say how how JIT will work by your design. Will it generate machine code directly to memory (like RuyJIT does it) or some other way? I can't find code generation in current implementation.

The instructions for running the JIT prototype are here: #6327. It only works on Windows right now. Hopefully it didn't bitrot yet: you should be able to step through it. This is using RyuJIT as the JIT (a lot of the managed infrastructure that communicates with RyuJIT is shared with the CoreRT AOT compiler).

The part where we do code generation is around here:

corert/src/System.Private.Jit/src/Internal/Runtime/JitSupport/RyuJitExecutionStrategy.cs

Line 84 in ecc96e7

_corInfoImpl.CompileMethod(codeNode);

@MichalStrehovsky it sounds great! do you have any stats about passed CoreCLR/FX tests?

I don't think anyone tried to run tests with this.

But this way looks more robust then new JIT compiler

Are there any examples or blog posts utilizing the interpreter or JIT?

#6182 has the interpreter instructions but the interpreter is not ready for serious workloads.

We stopped building the JIT prototype a couple days ago because there was an issue blocking an integration from the dotnet/runtime repo and stopping the builds was the fastest thing to do to get things unblocked. The JIT prototype has similar limitations to the interpreter prototype.

Interesting! Thanks for the quick reply, I cloned corert and built it then built the IL interpreter. Then created a new project with .NET Core 3.1 console app and added the System.Private.Interpreter as a reference DLL. Then started reading issue 5011 and am trying to wrap my head around creating a simple example :).

[Question] Assembly loading