| Age | Commit message (Collapse) | Author |
|---|
|
In December 2021, we opened an [issue] to solicit feedback regarding the
porting of the YJIT codebase from C99 to Rust. There were some
reservations, but this project was given the go ahead by Ruby core
developers and Matz. Since then, we have successfully completed the port
of YJIT to Rust.
The new Rust version of YJIT has reached parity with the C version, in
that it passes all the CRuby tests, is able to run all of the YJIT
benchmarks, and performs similarly to the C version (because it works
the same way and largely generates the same machine code). We've even
incorporated some design improvements, such as a more fine-grained
constant invalidation mechanism which we expect will make a big
difference in Ruby on Rails applications.
Because we want to be careful, YJIT is guarded behind a configure
option:
```shell
./configure --enable-yjit # Build YJIT in release mode
./configure --enable-yjit=dev # Build YJIT in dev/debug mode
```
By default, YJIT does not get compiled and cargo/rustc is not required.
If YJIT is built in dev mode, then `cargo` is used to fetch development
dependencies, but when building in release, `cargo` is not required,
only `rustc`. At the moment YJIT requires Rust 1.60.0 or newer.
The YJIT command-line options remain mostly unchanged, and more details
about the build process are documented in `doc/yjit/yjit.md`.
The CI tests have been updated and do not take any more resources than
before.
The development history of the Rust port is available at the following
commit for interested parties:
https://github.com/Shopify/ruby/commit/1fd9573d8b4b65219f1c2407f30a0a60e537f8be
Our hope is that Rust YJIT will be compiled and included as a part of
system packages and compiled binaries of the Ruby 3.2 release. We do not
anticipate any major problems as Rust is well supported on every
platform which YJIT supports, but to make sure that this process works
smoothly, we would like to reach out to those who take care of building
systems packages before the 3.2 release is shipped and resolve any
issues that may come up.
[issue]: https://bugs.ruby-lang.org/issues/18481
Co-authored-by: Maxime Chevalier-Boisvert <maximechevalierb@gmail.com>
Co-authored-by: Noah Gibbs <the.codefolio.guy@gmail.com>
Co-authored-by: Kevin Newton <kddnewton@gmail.com>
Notes:
Merged: https://github.com/ruby/ruby/pull/5826
|
|
note that YJIT does not work correctly on the platform now.
|
|
This was probably not intended in 85a426dc8678f04a78ffd799943b690ce2984c49.
|
|
- prerequisite of supporting YJIT with VC++.
- note that now can specfily `--yjit` on mswin64, but not enabled
YJIT'ed code because of YJIT requires `OPT_DIRECT_THREADED_CODE`
or `OPT_CALL_THREADED_CODE` in `rb_yjit_compile_iseq`.
|
|
* Rename --jit to --mjit
[Feature #18349]
* Fix a few more --jit references
* Fix MJIT Actions
* More s/jit/mjit/ and re-introduce --disable-jit
* Update NEWS.md
* Fix test_bug_reporter_add
Notes:
Merged-By: k0kubun <takashikkbn@gmail.com>
|
|
As part of YJIT's strategy for promoting Ruby constant expressions into
constants in the output native code, the interpreter calls
rb_yjit_constant_ic_update() from opt_setinlinecache.
The block invalidation loop indirectly calls rb_darray_remove_unordered(),
which does a shuffle remove. Because of this, looping with an
incrementing counter like done previously can miss some elements in the
array. Repeatedly invalidate the first element instead.
The bug this commit resolves does not seem to cause crashes or divergent
behaviors.
Co-authored-by: Jemma Issroff <jemmaissroff@gmail.com>
Notes:
Merged: https://github.com/ruby/ruby/pull/5221
|
|
* Add --yjit-no-type-prop so we can test YJIT without type propagation
* Fix typo in command line option
* Leave just two test workflows enable for YJIT
Notes:
Merged-By: maximecb <maximecb@ruby-lang.org>
|
|
|
|
|
|
Since this file is exposed to the rest of the codebase and they don't
really need to know about things like PLATFORM_SUPPORTED_P.
|
|
We were exporting a couple of symbols in yjit.h because they could be
used by code generated by MJIT. We don't want MJIT calling into YJIT
code anyways so let's stop exporting them to libruby.so.
Also adjust indentation and comments in mjit_exec().
|
|
For upstreaming, we want functions we export either prefixed with "rb_"
or made static. Historically we haven't been following this rule, so we
were "leaking" a lot of symbols as `make leak-globals` would tell us.
This change unifies everything YJIT into a single compilation unit,
yjit.o, and makes everything unprefixed static to pass `make leak-globals`.
This manual "unified build" setup is similar to that of vm.o.
Having everything in one compilation unit allows static functions to
be visible across YJIT files and removes the need for declarations in
headers in some cases. Unnecessary declarations were removed.
Other changes of note:
- switched to MJIT_SYMBOL_EXPORT_BEGIN which indicates stuff as being
off limits for native extensions
- the first include of each YJIT file is change to be "internal.h"
- undefined MAP_STACK before explicitly redefining it since it
collide's with a definition in system headers. Consider renaming?
|
|
|
|
The interpreter instruction count was enabled based on RUBY_DEBUG as
opposed to YJIT_STATS. In builds with YJIT_STATS=1 but RUBY_DEBUG=0,
the count was not available.
Move YJIT_STATS in yjit.h where declarations are expoed to code outside
of YJIT. Also reduce the changes made to the interpreter for calling
into YJIT's instruction counting function.
|
|
This change fixes some cases where YJIT fails to fire tracing events.
Most of the situations YJIT did not handle correctly involves enabling
tracing while running inside generated code.
A new operation to invalidate all generated code is added, which uses
patching to make generated code exit at the next VM instruction
boundary. A new routine called `jit_prepare_routine_call()` is
introduced to facilitate this and should be used when generating code
that could allocate, or could otherwise use `RB_VM_LOCK_ENTER()`.
The `c_return` event is fired in the middle of an instruction as opposed
to at an instruction boundary, so it requires special handling. C method
call return points are patched to go to a fucntion which does everything
the interpreter does, including firing the `c_return` event. The
generated code for C method calls normally does not fire the event.
Invalided code should not change after patching so the exits are not
clobbered. A new variable is introduced to track the region of code that
should not change.
|
|
If `--disable-jit-support` is passed to configure, then `jit_func` is
removed from the iseq body and we can't compile YJIT. This commit
detects when the JIT function pointer is gone and disables YJIT in that
case.
|
|
Always using `ret` to return to the interpreter means that we never have
to check the VM_FRAME_FLAG_FINISH flag.
In the case that we return `Qundef`, the interpreter will execute the
cfp. We can take advantage of this by setting the PC to the instruction
we can't handle, and let the interpreter pick up the ball from there.
If we return a value other than Qundef, the interpreter will take that
value as the "return value" from the JIT and push that to the SP of the
caller
The leave instruction puts the return value on the top of the calling
frame's stack. YJIT does the same thing for leave instructions.
However, when we're returning back to the interpreter, the leave
instruction _should not_ put the return value on the top of the stack,
but put it in RAX and use RET. This commit pops the last value from the
stack pointer and puts it in RAX so that the interpreter is happy with
SP.
|
|
|
|
|
|
* Implement eager versioning. Refactor versioning logic.
* Add --version-limit and --greedy-versioning command-line args
|
|
Make sure `opt_getinlinecache` is in a block all on its own, and
invalidate it from the interpreter when `opt_setinlinecache`.
It will recompile with a filled cache the second time around.
This lets YJIT runs well when the IC for constant is cold.
|
|
This commit collects statistics about how many binding objects are
allocated as well as the number of local variables set on bindings.
Statistics are output along with other YJIT stats. Here is an example
of the output:
```
***YJIT: Printing runtime counters from yjit.rb***
Number of Bindings Allocated: 195
Number of locals modified through binding: 0
opt_send_without_block exit reasons:
ivar_get_method 7515891 (40.4%)
se_cc_klass_differ 3081330 (16.6%)
iseq_argc_mismatch 1564578 ( 8.4%)
se_receiver_not_heap 1557663 ( 8.4%)
ic_empty 1407064 ( 7.6%)
optimized_method 995823 ( 5.4%)
iseq_not_simple 819413 ( 4.4%)
alias_method 706972 ( 3.8%)
bmethod 685253 ( 3.7%)
callsite_not_simple 225983 ( 1.2%)
kw_splat 25999 ( 0.1%)
ivar_set_method 902 ( 0.0%)
cfunc_toomany_args 394 ( 0.0%)
refined_method 42 ( 0.0%)
cfunc_ruby_array_varg 29 ( 0.0%)
invalid_cme 4 ( 0.0%)
leave exit reasons:
se_finish_frame 4067107 (100.0%)
se_interrupt 24 ( 0.0%)
getinstancevariable exit reasons:
undef 121177 (100.0%)
idx_out_of_range 5 ( 0.0%)
opt_aref exit reasons:
(all relevant counters are zero)
compiled_iseq_count: 3944
main_block_code_size: 1.1 MiB
side_block_code_size: 0.6 MiB
vm_insns_count: 1137268516
yjit_exec_insns_count: 414015644
ratio_in_yjit: 26.7%
avg_len_in_yjit: 7.5
total_exit_count: 55491789
most frequent exit op:
opt_send_without_block: 18587628 (33.5%)
opt_getinlinecache: 11075822 (20.0%)
send: 4949300 (8.9%)
leave: 4067131 (7.3%)
defined: 3975196 (7.2%)
setinstancevariable: 3567315 (6.4%)
invokesuper: 2982163 (5.4%)
getblockparamproxy: 2168852 (3.9%)
opt_nil_p: 2104524 (3.8%)
opt_aref: 2013858 (3.6%)
```
Running RailsBench allocates 195 binding objects but doesn't set any
local variables.
|
|
|
|
Renaming uJIT to YJIT. AKA s/ujit/yjit/g.
|
