JIT compiler toolchain


Hi, I don’t know if any of you are familiar with the pypy project. Most importantly, it’s a jit-compiler generator toolchain, ie you write a bytecode interpreter for some new language using a subset of python and add some useful hints. The jit-generator then adds a tracing jit which unrolls the main opcode dispatch loop to match the loops in the end-user program (the one written in the new language) and does his things on them. The important part is that it’s actually tracing and jiting the interpreter code, not the new language code. I feel like it would be a perfect match to use Rust to replace their RPython (a subset of python that’s kinda hard to work with: has almost no libs and documentation): Rust is already a compiled language, it has strong support for low-level (necessary to write a jit-compiler), for compile-time code execution (with macros and compiler plugins) to generate the jit and for code hints with attributes. Moreover, writing a jit(-generator) for Rust would be something useful in general as it can be used to speedup some other things like hardware simulators or maybe generic programs having lot’s of runtime-constant dependent hot-loops.

Has anybody already thought about this (a jit-compiler for Rust)?

Note: not sure if this category is specifically about rustc or about compilation and compilers of Rust.


We already have a basic Rust-Interpreter: miri.

All that’s required to interpret other languages with it is that the other languages generate MIR.

Of course it’s not a JIT, but it should totally be possible to write a JIT based on MIR. It would probably duplicate a lot of miri’s things, so it might be a third interpretation mode in miri


Nice, I didn’t know about miri. But actually the funny thing with jit-compiler generation is that there is absolutely no interpretation involved: during the compilation of the Rust code you emit tracing code at some places (maybe hinted ones or around loops) and also some control transfer (to stop executing the AOT-compiled code and switch to the JIT-compiler). That way you are actually tracing compiled code: the JIT-compiler and it’s subject run at the same level, namely the native architecture and thus there is no runtime plateform. In the pypy project, the traced code happens to be an interpreter but it could be extended to a wider class of programs.


Have you seen https://crates.io/crates/dynasmrt ?