This is always a problem for any JIT. Large codebases, especially ones as heavy on dynamic code paths as rails, run individual pieces of code less frequently th

This is always a problem for any JIT. Large codebases, especially ones as heavy on dynamic code paths as rails, run individual pieces of code less frequently than smaller ones (because they're just doing more work in general, and in rails' case are constantly spawning new code to deal with). Then you have to instrument the code while it's running under a VM to decide what (and how) to JIT, and then you have to compile and assemble it. You also probably have to deal with some quasi-locking around the call sites as you switch code from using the VM to using the JIT. So, basically by the laws of thermodynamics, all else equal a JITing VM will be slower than a non-JITing one, and the benefits of JIT won't kick in until you have enough code instrumented and compiled to make a dent in that performance loss from the extra work. And then, the cleverer your JIT, and the more you optimize the code under compile, the more off-balance this gets, because doing those things gets more expensive.