Project

General

Profile

Actions

Feature #19420

closed

Simplify MJIT implementation

Added by k0kubun (Takashi Kokubun) about 1 year ago. Updated about 1 year ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:112239]

Description

Background

Implementation complexity

Because MJIT needs to run a C compiler and be able to call almost everything in vm.c, it has brought MJIT-specific complexity to the Ruby VM implementation:

  • GVL and waitpid hacks for Process.waitall
  • vm_base_ptr dependency from MJIT
  • MJIT header and MJIT_HEADER macro
    • It seems like some build dependency is missing for it and my local build with -j randomly fails on MJIT header build.
  • MJIT-specific frame handling
    • catch_except_p flag in ISeq
    • jit_enable_p flag in vm_exec
    • leaf attribute in insns
  • MJIT_FUNC_EXPORTED functions

Third-party JIT experiments

Despite YJIT being the only non-experimental JIT compiler in CRuby from Ruby 3.2, people still experiment with other JIT implementations, e.g. vnmakarov/ruby (sir-mirjit), tenderlove/tenderjit, jhawthorn/hawthjit, which I think is a good thing for the future of Ruby, and for YJIT as well.

In Ruby 3.2, MJIT was rewritten in Ruby. It also meant that you could replace CRuby's JIT implementation by monkey-patching MJIT, which became the first ever "third-party JIT backdoor". I know two people started using it for that purpose. I want people (including myself through MJIT) to keep experimenting with Ruby performance, so I don't want to just get rid of this. RubyVM::MJIT::C and RubyVM::MJIT::Hooks are something that third-party gems can't easily provide. They should be considered as something similar to JVMCI (Java's JIT interface) whether we make them private or not.

Proposal

  • Change MJIT to a simple JIT implementation that doesn't rely on a C compiler at runtime, which works like YJIT (to remove all the complexity mentioned above) but is written in Ruby (to keep offerring modules for third-party JITs).
    • I have a PoC branch, which needs rebase and cleanup but passes make check. It currently supports very limited operations and is not really useful, but I intend to keep improving this outside my work hours (that I dedicate to YJIT), sometimes experimenting with things that are not done in YJIT. Note that we could still solve the above problems even with the current patch.
    • It shouldn't increase the maintenance cost of CRuby too much.
      • You're free to just mark something "can't compile" in MJIT when VM is changed.
      • It should also not support platforms that YJIT doesn't support. When it's upstreamed for the first time, I intend to make it like Ruby 3.1 YJIT, i.e. supporting only x86_64 Linux and BSD.
    • It's also kind of useful in the sense that it requires neither a C compiler at runtime nor a Rust compiler at build time.
    • I'm thinking about renaming it to "RJIT" ("R"uby "JIT") since it's no longer a "M"ethod "JIT" anymore.
    • Note that part of the implementation cannot be implemented as a gem. RubyVM::MJIT::C (that uses Primitive) and RubyVM::MJIT::Hooks (that are hooked from VM internals) must be part of the interpreter. I'm open to making other parts a gem if other people want me to, but it might come with a maintainability trade-off because of that interpreter dependency.
Actions

Also available in: Atom PDF

Like1
Like0Like0Like0Like1Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0