Matz (Ruby lead maintainer/original author) has said that Ruby 2.7 (coming out this Christmas) has JIT improments that make JIT neutral for Rails. The goal is to have it be net positive by Ruby 3.0 (Christmas 2020)
It's a dynamic language. Typical JIT compilation involves generating specialized versions over specific types. You need run time profiling to know what to generate.
Seems like the profile from run 1 would be pretty predictive of run 2. And the profile and cache can be updated during each run.
Some experiments are underway soon, current implementation uses a cache that is tightly scoped to a specific run including stuff such as class serial numbers that can not be reused between runs safely
Re:JIT and Ruby's MJIT
by ShroudedNight on Friday December 06, 2019 @08:54PM
(#21727931)
>> MJIT will slow Rails down instead of speeding it up.
>> That’s a pretty significant footnote.
> Oops.
FWIW / from what I remember, generating high-performance native code for Rails was hard (or at least significantly different from optimizing standard benchmark type code). The OMR JIT for Ruby had similar challenges, with at least a few 'at least we didn't make it worse' moments.
I was only tangentially involved, but I vaguely recall Rails needing (or at least appearing to need) a lot more inlining and string manipulation optimizations to fly.
> Why not cache the compiled methods to make warmup a once-per-version delay? It would be a JIT/precompiled hybrid. Call it gradually compiled.
That's what Bootsnap does, and it now comes standard with Rails. https://github.com/Shopify/bootsnap
> That’s a pretty significant footnote.
Oops.
> In addition to memory usage, there’s warmup time. With JIT, the interpreter has to recognize that a method is called a lot and then take time to compile it. That means there’s a delay between when the program starts and when it gets to full speed.
Why not cache the compiled methods to make warmup a once-per-version delay? It would be a JIT/precompiled hybrid. Call it gradually compiled.