Open alpencolt opened 5 years ago
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: https://github.com/dotnet/corert/blob/ecc96e76c51ca55ff885e08aefb5d7cbdeed36a5/src/System.Private.Jit/src/Internal/Runtime/JitSupport/RyuJitExecutionStrategy.cs#L84
@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?
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 :).
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:dlopen
). Can it work?cc @jkotas @kvochko @iarischenko @kbaladurin