[ruby-core:105688] [Ruby master Feature#18229] Proposal to merge YJIT

["matz (Yukihiro Matsumoto)" <noreply@ruby-lang.org>]

Issue #18229 has been updated by matz (Yukihiro Matsumoto).


I accept @maximecb as a committer. Welcome!

For the concrete process for merging YJIT into master, consult with @k0kubun.

Matz.


----------------------------------------
Feature #18229: Proposal to merge YJIT
https://bugs.ruby-lang.org/issues/18229#change-94188

* Author: maximecb (Maxime Chevalier-Boisvert)
* Status: Assigned
* Priority: Normal
* Assignee: k0kubun (Takashi Kokubun)
----------------------------------------
# Background

YJIT is a new open source JIT compiler for CRuby.  The project is led by a small team at Shopify in collaboration with developers from GitHub.  The key advantages of this project are that the compiler delivers very fast warm-up and has fine grain control over the entire compiler pipeline.

This JIT translates YARV instructions to machine code and employs a technique known as [Lazy Basic Block Versioning (LBBV)](https://drops.dagstuhl.de/opus/volltexte/2015/5219/pdf/9.pdf) in order to specialize code based on types seen at run-time and reduce generated code size without needing to do static type analysis. The YJIT project was [presented at RubyKaigi 2021](https://www.youtube.com/watch?v=PBVLf3yfMs8).

# Limitations

YJIT works by translating YARV instructions to x86 machine code.  YJIT doesn’t support all YARV instructions, but is able to gracefully handle unknown instructions by returning control of execution back to the CRuby interpreter.

Today, YJIT only targets x86-64 architecture.  We may support ARM64 in the future, but due to the nature of the compiler design, we can’t easily support as many platforms as MJIT. Still, we anticipate that x86-64 and ARM64 will cover the needs of the vast majority of users, from PCs to servers to Apple M1s to cell phones and even Raspberry Pis.

# Advantages

YJIT has very fast warmup and can produce good real-world benchmark results when compared to other JITs. There are still many options for improving performance further.

# Integration with MRI

YJIT can’t work fully as a “plug-in” JIT.  It requires some modifications to CRuby, mostly related to compilation and invalidation.  For example, YJIT needs callbacks so it can be notified when the constant state changes or when BOPs are redefined.  These modifications are quite modest and could be advantageous for MJIT or other JITs in the future.  YJIT’s implementation is contained in the yjit_*.c files with very few modifications to CRuby.

# Benchmarks

YJIT optimizes a number of common benchmarks well. Here are some results compared to the CRuby interpreter without MJIT, [current as of Sept 2021](https://speed.yjit.org/benchmarks/bench-2021-09-27-071059):

activerecord: 1.37x
jekyll: 1.12x
liquid-render: 1.27x
mail gem: 1.09x
psych-load: 1.29x
Kokubun's railsbench: 1.16x
optcarrot: 1.68x
Chris Seaton's lee benchmark: 1.41x

Source code for these benchmarks can be found at https://github.com/Shopify/yjit-bench under "benchmarks".

# TODO / Known Bugs

We have been running YJIT in production, but it is still experimental.  Some key features are currently missing, the most important being “code GC”.  Currently, any generated code that is invalidated (or becomes “unusable”) is not collected, nor is the memory allocated for that code reclaimed.  This is rarely a problem in practice because most Ruby programs generate a fixed amount of code, but it is a problem that we want to fix in the short to medium term. This is an area which is currently under development.

# Stability and Compatibility

MRI’s full suite of tests including RubySpec tests pass with YJIT enabled.  We’ve tested YJIT against our production application (Shopify’s StoreFront Renderer) and all tests pass there as well.  Finally, GitHub has tested YJIT against their test suite and all tests pass.  We’ve deployed YJIT to production on a subset of servers and seen performance improvements.  See more details here.

# Merging Proposal

Despite some of the limitations and TODO’s listed here, we would like to propose merging YJIT so that we can get feedback from the rest of the community as well as add “integration points” for other JIT implementations.

We’ve intentionally made as few changes to MRI as possible to support integrating YJIT.  We’re committed to continue developing YJIT, but intentionally kept the changes to MRI small in order to ease the burden on upstream maintainers.

YJIT will be disabled by default and require an experimental command-line flag (`--yjit`) to be set.




-- 
https://bugs.ruby-lang.org/