Skip to content
This repository has been archived by the owner on Nov 1, 2020. It is now read-only.

Restore JIT prototype #6327

Merged
merged 1 commit into from
Sep 13, 2018
Merged

Conversation

MichalStrehovsky
Copy link
Member

The JIT prototype was originally brought up on the closed source ".NET Native for UWP apps" compiler/runtime, so this is mostly to adapt it for CoreRT.

Surprisingly, this hasn't bit rotten much over time and some of the bitrot has been cleaned up by @tonerdo in his interpreter work (#6182). Both an interpreter and a JIT are a great addition to a fully AOT compiled runtime and they complement each other nicely.

With this, I'm making the JIT prototype work on CoreRT:

  • Adjust the hacks that were used by JIT code manager to talk to the runtime (in CoreRT, runtime is linked into the executable and the hacks didn't work). This will need further cleanup at some point.
  • Rename ReaderWriterLock because it was conflicting with a type of the same name in the runtime.
  • Add an experimental flavor of the stack trace decoder. This needs to use the experimental type loader.
  • Expose the JIT component from MSBuild - compile JIT support into the executable, use the experimental flavor of the reflection stack (shared with the interpreter), add the extra native library with JIT support. This is to allow enabling JIT support as part of dotnet publish.

You can try this out pretty much the same way as @tonerdo's interpreter: see instructions in #6182. Instead of passing /p:ExperimentalInterpreterSupport=true, pass /p:ExperimentalJitSupport=true. You'll need to manually copy clrjitilc.dll from the compiler to the publish directory (we use the same codegen that is used to compile the AOT parts of the application to also JIT compile at runtime).

The JIT prototype was originally brought up on the closed source ".NET Native for UWP apps" compiler/runtime, so this is mostly to adapt it for CoreRT.

Surprisingly, this hasn't bit rotten much over time and some of the bitrot has been cleaned up by @tonerdo in his interpreter work (dotnet#6182). Both an interpreter and a JIT are a great addition to a fully AOT compiled runtime and they complement each other nicely.

With this, I'm making the JIT prototype work on CoreRT:

* Adjust the hacks that were used by JIT code manager to talk to the runtime (in CoreRT, runtime is linked into the executable and the hacks didn't work). This will need further cleanup at some point.
* Rename ReaderWriterLock because it was conflicting with a type of the same name in the runtime.
* Add an experimental flavor of the stack trace decoder. This needs to use the experimental type loader.
* Expose the JIT component from MSBuild - compile JIT support into the executable, use the experimental flavor of the reflection stack (shared with the interpreter), add the extra native library with JIT support. This is to allow enabling JIT support as part of `dotnet publish`.

You can try this out pretty much the same way as @tonerdo's interpreter: see instructions in dotnet#6182. Instead of passing `/p:ExperimentalInterpreterSupport=true`, pass `/p:ExperimentalJitSupport=true`. You'll need to manually copy clrjitilc.dll from the compiler to the publish directory (we use the same codegen that is used to compile the AOT parts of the application to also JIT compile at runtime).
@MichalStrehovsky
Copy link
Member Author

What works is this:

using System;
using System.IO;
using System.Reflection;

internal class Program
{
    static void Main(string[] args)
    {
        byte[] buffer = File.ReadAllBytes(@"D:\repro\minimal.exe");
        var assembly = Assembly.Load(buffer);
        var entryPoint = assembly.EntryPoint;
        int code = (int)entryPoint.Invoke(null, null);
        Console.WriteLine(code);
    }
}

Where minimal.exe has this:

static class Program
{
    static int Main()
    {
        return 100;
    }
}

I think more stuff will work, but I don't remember how much was actually brought up. I might look into this over some weekends more, but even just this pull request is something that has been sitting on my computer for weeks and I couldn't find the time to finish it... so...

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@MichalStrehovsky MichalStrehovsky merged commit 3ca0b10 into dotnet:master Sep 13, 2018
@MichalStrehovsky MichalStrehovsky deleted the jitPrototype branch September 13, 2018 15:16
@drearyrainDeng
Copy link

Question:what is different between JIT and and interperter #6182?. it seems do same work! thanks advance!

@jkotas
Copy link
Member

jkotas commented May 13, 2019

what is different between JIT and and interperter

Interpreter is simpler, more portable, has better startup performance and worse steady steady state performance. JIT is more complex, less portable, has worse startup performance and better steady state performance. This is frequently asked question:
https://www.bing.com/search?q=difference+between+jit+and+interpreter

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants