Making a Just-In-Time compiler is complex, a large source of security issues, and is a price which is frequently paid to have better performance results.

HolyJit is made to remove this trade-off! Simplicity and security should no longer be sacrificed for performance reasons.

HolyJit

HolyJit is a high-level Just-In-Time compiler. It extends the Rust compiler to convert the code of an interpreter written in Rust to tune a JIT compiler to handle the same interpreted language.

HolyJit aims at being:

• Easy.
• Safe.
• Fast.

Easy

HolyJit extends the Rust compiler to copy its internal representation of functions and convert it into a representation which can be consumed by the JIT compiler provided by HolyJit library.

As a user, this implies that to inline a function in JIT compiled code, one just need to annotate it with the jit! macro:

jit!{
    fn eval(script: &Script, args: &[Value]) -> Result<Value, Error>
    = eval_impl
    in script.as_ref()
}

fn eval_impl(script: &Script, args: &[Value]) -> Result<Value, Error> {
    // ...
    // ... A few hundred lines of ordinary Rust code later ...
    // ...
}

fn main() {
    let script = ...;
    let args = ...;
    // Call it as any ordinary function.
    let res = eval(&script, &args);
    println!("Result: {}", res);
}

Thus, you basically have to write an interpreter, and annotate it properly to teach the JIT compiler what can be optimized by the compiler.

No assembly knowledge is required to start instrumenting your code to make it available to the JIT compiler's set of known functions.

Safe

Security issues from JIT compilers arise from:

• Duplication of the runtime into a set of MacroAssembler functions.
• Correctness of the compiler optimizations.

As HolyJit extends the Rust compiler to extract the effective knowledge of the compiler, there is no more risk of having correctness issues caused by the duplication of code.

Moreover, the code which is given to the JIT compiler is as safe as the code users wrote in the Rust language.

As HolyJit aims at being a JIT library which can easily be embedded into other projects, correctness of the compiler optimizations should be caught by the community of users and fuzzers, thus leaving less bugs for you to find.

Fast

Fast is a tricky question when dealing with a JIT compiler, as the cost of the compilation is part of the equation.

HolyJit aims at reducing the start-up time, based on annotations made out of macros, to guide the early tiers of the compilers for unrolling loops and generating inline caches.

For final compilation tiers, it uses special types/traits to wrap the data in order to instrument and monitor the values which are being used, such that guards can later be converted into constraints.

Using HolyJit

HolyJit is a rustc driver, which means that it has to be used in-place of rustc or as a rustc wrapper, i.e. by settings either the RUSTC or RUSTC_WRAPPER environment variable.

When holyjit is used, the binary is instrumented the generated code with enough information to resume with the JIT compilation at runtime.

When rustc is used, a binary is still produced but the JIT is disabled as no data are stored in the binary to be consumed by the JIT compiler at runtime.

To run tests, you can either run the test of the library with cargo test, or run the examples of HolyJit with:

$ RUSTC_WRAPPER=$(pwd)/rustc.sh cargo run --example brainfuck --verbose

At the moment, HolyJit is far from being yet ready for production! This is currently at a prototype stage, and most of the code & dependencies present today were made only as a proof of concept and not as a definitive implementation design.

HolyJit Roadmap for 0.0.0

The current goal is to make a proof of concept which highlights the main feature, i.e. being trivial to integrate into an existing code base and to have a running JIT compiler.

As of today, HolyJit contains a draft of what the interface might look like, and is able to generate code for the example present in the repository.

• Create Rust library

  • Allocate pages and map them as executable.
  • Add a way to call either a dynamically compiled function or a statically compiled function.
  • Add a jit! macro, to make calls transparent from the usage point of view.
  • Create a JitContext class, and use it to request JIT compiled code.
  • Create a graph representation.
  • Consume the graph to generate code.

• Create a MIR plugin

  • Detect locations which have to be patched.
  • Find functions which have to be converted.
  • Inject a generated vector in the binary content.
  • Inject static variables as a tuple.
  • Collect static variable references.
  • Convert the MIR (from the Rust compiler) to the library graph representation.