O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
Ruby JIT Compilation - the talk and presentation prepared by the experienced developer and lecturer Mykhailo Bortnyk for the Ruby Meditation conference. The presentation contains JIT definition, known Ruby JIT implementations, demonstration, and some considerations on the future of JIT in Ruby.
Ruby JIT compilation
gain speed with (little) pain
Special thanks to
for all your support
● Mykhailo Bortnyk
● Language researcher
○ #3 contributor of mruby/c
● Co-creator of Kottans
○ lecturer from very beginning till 2016
○ currently community is self-driving
● Social media
○ github: @vessi
○ twitter: @mikhailbortnyk
○ facebook: @vessimir
● What is JIT
● Known Ruby JIT implementations
● Demo time
● Future of JIT in Ruby
What is JIT
“JIT compilation compiles a piece of application code at runtime into binary
machine code, then allows the VM to execute the generated code directly rather
than interpret the original piece of application code. It is like treating the entire
piece of application code as a single super instruction”.
Xiao-Feng Li, “Advanced Design and Implementation of Virtual Machines”
What is JIT
JIT, just-in-time compilation, in other words dynamic translation - technology
to improve bytecode systems (in fact, almost every interpreter).
Actually, it just compiles some methods, blocks or regions to machine code to
speed up performance of bytecode execution.
Also exists in PHP (HipHop), SmallTalk (GemStone), Perl.
JIT use case
● Well, interpreters are slow
● So, step 1: compile strings of code to bytecode
● Still slow
● Step 2: compile some bytecode to machine code
● Now better
● Step 3: drop your language and write your software in C
● Err… let’s better stop on step 2
JIT (very) short history
● Very first and very naïve JIT implementation by McCarthy for LISP in 1960
● Second JIT implementation by Ken Thompson for QED regular expressions in
○ Mitchell, 1970, language LC^2
○ Sun Microsystems, 1983, Smalltalk. Self VM was only 2x slower than plain C
○ James Gosling, 1993, Java. Invented term Just-in-time
○ Michael Franz, 1994, Oberon. Dissertation “Code Generation on-the-fly: a key to portable
○ RubyMotion team, 2012, Ruby on LLVM (translation to Objective C)
○ Maglev team, 2011, Ruby on Smalltalk GemStone VM (by VMWare)
○ Takashi Kokubun, 2017, Ruby with LLVM binding
○ Vladimir Makarov, 2017, Ruby native JIT implementation
Types of JIT
JIT implementations in general can be grouped into 3 types:
● Method-based JIT (replaces original implementation in class VTable with
native function call)
● Trace-based JIT (only compiles code on specific execution path, path is
identified through profiling)
● Region-based JIT (hybrid between method- and trace-based
How JIT loads native code
● Interpreter loads vtable
● Interpreter sends
bytecode to compiler
● Interpreter replaces
bytecode with native
JRuby was originally created in 2001 by Jan Petersen and was just one-to-one
port of Ruby 1.6 code. JIT was not implemented at this time.
From version JRuby 1.1 JIT support were added together with Ruby 1.8.7 support.
JIT compiles Ruby bytecode to JVM bytecode. Uses region-based JIT.
Able to work with GraalVM from version 9.x.x.x
● Needs warm up time
● Needs more memory
● Eliminates GIL
Created in 2009 by Evan Phoenix basing on “Blue Book” of Smalltalk-80. Uses
principle “implement most of Ruby in Ruby itself”.
JIT is method-based. Counts method calls and method hash (to expire JIT result
on method modification).
If method is called more than LIMIT times - adds it to JIT queue. JIT queue is
managed by background native thread which replaces bytecode of warm method
with call of native instructions.
Maglev is alternative Ruby implementation created in 2008 on top of GemStone/S
Smalltalk virtual machine by GemTalk company.
Targeted Ruby 1.8.7, had one-to-one Ruby/Smalltalk thread mapping, shared VM
state storage and SmallTalk JIT from GemStone VM (trace-based JIT AFAIK,
can’t check, GemStone/S is dead).
Project is dead (last commit 2 years ago, active development stopped in 2015).
deoptimization branch by Shyohei Urabe
This branch contained first naïve implementation of JIT, used very few of JIT
optimizations, but uses less memory than full-power JIT implementation.
Submitted at 26 Aug 2016.
Not merged (and will not be).
Reference URL: https://github.com/ruby/ruby/pull/1419
MJIT by Vladimir Makarov
JIT implementation made by Vladimir Makarov, author of Ruby 2.4 hash tables
reimplementation, worker of RedHat.
Author held RubyKaigi keynote in 2017.
Converted YARV to register-based instead of stack-based (smaller instructions
but larger memory footprint). Built JIT on top of new VM implementation.
MJIT can reach 230% performance of Ruby 2.0.0 but is pretty unstable.
LLRB by Takashi Kokubun
Created by Takashi Kokubun. Inspired by earlier Evan Phoenix’s work.
Contains manually callable LLVM Ruby port.
Uses gem `llrb` as frontend to LLVM compiler, should be used with specially
patched version of Ruby 2.5 (actually, some C constants just made public
Supports almost all YARV instructions.
MJIT-YARV by Takashi Kokubun
Based on Vladimir Makarov’s work, but without changing Ruby VM to register-
based. Several JIT optimizations were turned off.
These reverted changes made JIT slower but more stable.
Reference PR: https://github.com/ruby/ruby/pull/1782
Reference ticket: https://bugs.ruby-lang.org/issues/14235
Partially merged in trunk 10 days ago.
Able to run Rails stably.