The document discusses Just-In-Time (JIT) compilation in Ruby, explaining its purpose, history, and different implementations like JRuby, Rubinius, and MJIT. It highlights how JIT compilation improves performance by converting application code into machine code at runtime, and outlines various techniques and their evolution. The presentation concludes with a mention of the future of JIT in Ruby and opportunities for Ruby developers.

1. Ruby JIT compilation
gain speed with (little) pain

2. Special thanks to
Amoniac OÜ
for all your support
<3

3. About me
● Mykhailo Bortnyk
● Language researcher
○ working with Ruby, C, JavaScript, Erlang
○ #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

4. ● What is JIT
● Known Ruby JIT implementations
● Demo time
● Future of JIT in Ruby
Presentation plan

5. What is JIT

6. 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”

7. 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.
Used in: Java, some JavaScript implementations, .NET framework, PyPy Python.
Also exists in PHP (HipHop), SmallTalk (GemStone), Perl.

8. 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
● PROFIT!

9. 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
1968
● Milestones:
○ 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
software”
○ 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

10. 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
implementations)

11. How JIT loads native code
● Interpreter loads vtable
● Interpreter sends
bytecode to compiler
● Interpreter replaces
bytecode with native
call

12. Ruby JIT implementations

13. JRuby
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

14. Rubinius
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.

15. Maglev Ruby
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).

16. 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

17. 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.

18. 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
exportable).
Supports almost all YARV instructions.
github: https://github.com/k0kubun/llrb

19. 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.

20. Demo time
source at github://vessi/rm20.git

21. Future of JIT in Ruby

22. Well, it will just appear in 2.6 release.
You don’t need to wait to 3.0

23. Q&A time

24. Thanks!

25. My friends are looking for
normal Ruby developer
(not another me)