The Ruby+OMR JIT compiler adds a JIT to CRuby. However, it has challenges to surmount before it will provide broad improvement to Ruby applications that aren’t micro-benchmarks. This talk will cover some of those challenges, along with some brainstorming about potential ways to tackle them. The Ruby+OMR JIT compiler is one way to add JIT compilation to the CRuby interpreter. However, it has a number of challenges to surmount before it will provide broad improvement to Ruby applications that aren’t micro-benchmarks. This talk will cover some of those challenges, along with some brainstorming about potential ways to tackle them.

1. Matthew Gaudet, February 4th, 2017
Highly Surmountable
Challenges in Ruby+OMR JIT
Compilation

2. What’s Ruby+OMR again?

3. An Open Source Toolkit for Language
Runtime Technologies.

4. Garbage
Collector
JIT Compiler
Monitoring
Porting Library
…More!

5. Goal: Compatibility!
Integrate vs. Replace

6. +

8. 8

9. Status Update: 13 Months later

10. 10

11. 11
No JIT….

13. 13

14. 14

15. Today:
 Branch ruby_2_4_omr is current default.
– Based of ruby_2_4 tag
 JIT Compiler Hooked up and running Travis tests for OS/X and Linux
– Known issues in make test-all
– Passing make test with count=0
 Populated and tagged Issue Tracker
 Performance: Less specialization to micro benchmarks, means lower
seeming performance.
– Better software engineering 
https://github.com/rubyomr-preview/ruby/issues/

16. JIT integration
 Functional Correctness has been primary objective
– Aiming for pass of test suite at all optimization levels.
–No restrictions on native code used by extension modules
 Have added some optimizations, but haven’t done much in the way of
tuning.
 Simple compilation control

18. Our Goal:
YES
Be Part of Delivering 3x3

19. Why?
 We think Ruby could really benefit from having a JIT
compiler.
 Lots of pre-built JIT compiler technology in OMR, with
potential for exploitation in Ruby.
 What’s in it for us? Validation of the OMR approach
–Community improvement: Having multiple consumers
helps us make it better for everyone!

20. https://twitter.com/ChrisGSeaton/status/811303853488488448

21. Competition and Collaboration
 Having multiple JITs for CRuby could be a really good thing!
 Share the load of creating interface and infrastructure that all
JITs for CRuby can rely on.
 Competition helps push things forward
 Collaboration helps solve hard problems!
21

22. 22 https://twitter.com/ChrisGSeaton/status/811332662350794752

23. 23
Effort!
Results!

25. Community Challenges!

26. https://twitter.com/tenderlove/status/765288
21993188147226

27. Make Tradeoffs that are Right for the Ruby Community
JIT Compilation:
 Trade startup speed for peak speed.
 Trade footprint for speed.

28. What do we prioritize?
Time to First Request?
Time to Peak
Performance?
Peak Performance?
100
64 69
36
25 30 25 26 25 26 25
1 2 3 4 5 6 7 8 9 10 11
Time per Iteration (s)
Prioritization will be driven by
benchmarks from the community.

29. 1. Some CPU intensive applications: OptCarrot
2. Some memory intensive application:
3. A startup benchmark: time ruby -e “def f; ‘100’; end; puts f”?
4. Some web application framework benchmark(s)?
http://rubykaigi.org/2016/presentations/MattStudies.html
Benchmarks to aim for?
http://engineering.appfolio.com/appfolio-engineering/2016/12/8/benchmarking-rails

30. Information Challenges

31. MRI
Garbage
Collector
Ruby IL
Generator Optimizer Code
Generator
Runtime Code Cache
YARV
Interpreter

32. JIT VM Symbiosis
VMJIT
Performance
Information
JIT ↔ VM Interface

33. Infrequent Event Notification
Operations such as
 Basic Operation Redefinition
 Constant Modification
 Class Hierarchy changes.
Unlocks:
–More aggressive specialization, class hierarchy
optimization. Don’t create code for things that haven’t
happened yet!

34. Stack Peeking Notification
 A hook that fires when some piece of code wants to look at a
stack frame – Give the JIT compiler a chance to materialize
what it should have looked like.
 Unlocks
–On Stack Replacement: Don’t Execute Code for Things
that might happen!

35. Basic Block Frequencies
How many times has this basic block been executed?
Unlocks:
Better Optimization: Don’t spend time compiling
on things that won’t get executed!
?

36. Type Profiling
What types have we seen for this value?
Unlocks:
Speculation and Specialization: Generate code for
the cases we think will happen!

37. Horizon Challenges

39. Much of MRI’s core functionality is written in C!
A problem for the optimization horizon!

40. Optimization Horizon Solutions?
 Rewrite all of core in Ruby.
 ‘Lift the Core’
40

41. Optimization Horizon Solutions?
Incremental Ruby-fication:
 More promising… and easy to get started on in Ruby!
 Convert prelude.rb to a ‘prelude’ directory, where Ruby implementations
live.
– Startup concerns (parse overheads) – can be mitigated with YARV
bytecode serialization.
– Longer term: JIT AOT Compilation maybe!
41

42. Optimization Challenges

43. An admission:

44. Testing Challenges

45. JIT Testing is Hard!
Normal Tests
 Finish quickly
 Coverage with minimal repetition.
 Local reasoning / isolation
 No special command lines
Compiler Stress Tests
 Need to run code multiple times!
– Allow the JIT to kick in, profile data
to be collected, and consumed
 Potentially require global
reasoning.
 Run in multiple VM instances
under different options.
Writing test cases that can effectively
stress the JIT compiler is an art

46. JIT Testing is Hard!
Other problems:
 Isolating test cases from each
other
 Time accuracy trade off
 Coverage
All these problems of JIT
testing will also be equally
true when running a
gem’s test suite with a
JIT...

47. My Personal Ruby Hero
Patched ruby/spec to
allow it to work with
repetition
Great win for JIT testing!

48. Engineering Challenges

49. Keeping up with the firehose?
How do we keep up to date with the Ruby core?
Some is good software engineering… callback generation was
done precisely to address this concern. But more still needed!

50. The JIT Needs some cleanup 
 Callback Generator Ruby code isn’t very good!
–https://github.com/rubyomr-preview/ruby/issues/74
 Great task for someone good at writing Ruby!
 The makefiles need love
– https://github.com/rubyomr-preview/ruby/issues/8

51. OMR Challenges

52. OMR is evolving!
We’ve only been open source for 4.5 months!
Still working on improving our interfaces, our
integration story.
Need to build out a community! This is where you
can help!

53. Mentorship
I’m committed to helping anyone who
wants to contribute to Ruby+OMR
get up and running.
I’ll write documentation
for things that are
unclear
I’ll answer email!
I’ll help guide
implementationI’ll be on slack!
I’ll schedule a video chat
with you!

54. Ruby+OMR needs community
interest to survive!

55. My To-Do List!
1. Make My Mentorship Commitment Clear!
2. I need to start collecting feedback from ruby-core
on what we would need to do to get community
members interested.
3. I need to start demonstrating the kinds of VM
changes a JIT will need.

56. The Audience To-Do List!
1. Give Ruby+OMR a try
2. Open Issues!
3. Ask about helping! Little things are equally
appreciated!

57. My thoughts on hitting 3x3:
57
The Work Ahead!
JIT Work VM Work
The VM Work I
hope can be shared
among competition!

58. Thank you so much!

59. Acknowledgements
 https://en.wikipedia.org/wiki/Foundation_%28engineering%29#/media/File:Concrete_cellar_
10007.JPG
http://emojipedia.org/mozilla/firefox-os-
2.5/confused-face/