What we can do with Ruby's JIT • Optimize Ruby methods to native code for hot spots • Eliminate VM interpretation cost: SP / PC • Optimize based on what C compiler can know • Ruby VM-specific optimizations we implemented
What we CAN'T do with Ruby's JIT • Optimize a short-running program • JIT needs time to optimize many methods • Things may be slower while a C compiler is running • Optimization based on native code generated by C compiler • Deoptimization based on native insn pointer / stack pointer
What should we do? • Current status: • Programs like Optcarrot run faster • Sinatra, Rails are still slightly slower than no-JIT mode • Let’s take a look at each of major Ruby features and JIT core
Inline C method call • Inlining C method had been hard because of: • Difficulty of detecting whether it’s safe to omit a call frame or not • Lots of indirection between method call and actual C function
Allow exception on "inline" method • A method which raises an exception can't have “inline" • But many methods raise: • TypeError • NoMemoryError • We could lazily update backtrace and others?
Optimize VM -> JIT call • VM -> JIT call is slower than VM -> VM call • We might be able to offset icache miss's slowness by this • Prepare a fastpath / VM insn specialized for JIT call