This repository was archived by the owner on Nov 1, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 1, 2020. It is now read-only.
[Question] Assembly loading #6949
Description
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 Support for IL interpreter in CoreRT #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?
Activity
jkotas commentedon Feb 4, 2019
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.
Loading libraries compiled in native library mode is not really
Assembly.LoadFileequivalent. 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 ofSystem.Object, etc.alpencolt commentedon Feb 4, 2019
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?
jkotas commentedon Feb 4, 2019
Both are early prototypes. A lot of work to finish.
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.
alpencolt commentedon Feb 4, 2019
An in this case we have to keep all system DLL, right?
jkotas commentedon Feb 4, 2019
Right. It becomes very much like what CoreCLR looks today.
alpencolt commentedon Feb 5, 2019
@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.
MichalStrehovsky commentedon Feb 5, 2019
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
alpencolt commentedon Feb 5, 2019
@MichalStrehovsky it sounds great! do you have any stats about passed CoreCLR/FX tests?
MichalStrehovsky commentedon Feb 5, 2019
I don't think anyone tried to run tests with this.
alpencolt commentedon Feb 5, 2019
But this way looks more robust then new JIT compiler
NotoriousRebel commentedon Apr 15, 2020
Are there any examples or blog posts utilizing the interpreter or JIT?
MichalStrehovsky commentedon Apr 15, 2020
#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.
NotoriousRebel commentedon Apr 15, 2020
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 :).