ruby.git/yjit/src/codegen.rs, branch v4.0.2 The Ruby Programming Language YJIT: Fix not reading locals from `cfp->ep` after `YJIT.enable` and exceptional entry 2026-03-16T18:03:25+00:00 Alan Wu XrXr@users.noreply.github.com 2026-03-12T22:33:00+00:00 8466e93b1d6eb85ad5952ab3a10575fa453e77e2 [Backport #21941] In case of `--yjit-disable`, YJIT only starts to record environment escapes after `RubyVM::YJIT.enable`. Previously we falsely assumed that we always have a full history all the way back to VM boot. This had YJIT install and run code that assume EP=BP when EP≠BP for some exceptional entry into the middle of a running frame, if the environment escaped before `YJIT.enable`. The fix is to reject exceptional entry with an escaped environment. Rename things and explain in more detail how the predicate for deciding to assume EP=BP works. It's quite subtle since it reasons about all parties in the system that push a control frame and then run JIT code. Note that while can_assume_on_stack_env() checks the currently running environment if it so happens to be the one YJIT is compiling against, it can return true for any ISEQ. The check isn't necessary for fixing the bug, and the load bearing part of this patch is the change to exceptional entries. This fix is flat on speed and space on ruby-bench headline benchmarks. Many thanks for the community effort to create a small test case for this bug. 
[Backport #21941]

In case of `--yjit-disable`, YJIT only starts to record environment
escapes after `RubyVM::YJIT.enable`. Previously we falsely assumed that
we always have a full history all the way back to VM boot. This had YJIT
install and run code that assume EP=BP when EP≠BP for some exceptional
entry into the middle of a running frame, if the environment escaped
before `YJIT.enable`.

The fix is to reject exceptional entry with an escaped environment.
Rename things and explain in more detail how the predicate for deciding
to assume EP=BP works. It's quite subtle since it reasons about all
parties in the system that push a control frame and then run JIT code.

Note that while can_assume_on_stack_env() checks the currently running
environment if it so happens to be the one YJIT is compiling against, it
can return true for any ISEQ. The check isn't necessary for fixing the
bug, and the load bearing part of this patch is the change to
exceptional entries.

This fix is flat on speed and space on ruby-bench headline benchmarks.

Many thanks for the community effort to create a small test case for
this bug.
JIT: Move EC offsets to jit_bindgen_constants 2025-12-18T21:43:45+00:00 John Hawthorn john@hawthorn.email 2025-12-18T20:31:34+00:00 73e930f9f911cf71ecb416c3112a7818bae41cd6 Co-authored-by: Alan Wu <alanwu@ruby-lang.org> 
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>
Co-authored-by: Luke Gruber <luke.gru@gmail.com> 2025-12-18T21:43:45+00:00 John Hawthorn john@hawthorn.email 2025-12-18T20:31:07+00:00 b1c3060beda4bd659d21a2b2ea598bf9ee819d70 Co-authored-by: Alan Wu <alanwu@ruby-lang.org> YJIT: Support calling bmethods in Ractors Co-authored-by: Luke Gruber <luke.gru@gmail.com> Suggestion from Alan 
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>

YJIT: Support calling bmethods in Ractors

Co-authored-by: Luke Gruber <luke.gru@gmail.com>

Suggestion from Alan
YJIT: Support calling bmethods in Ractors 2025-12-18T21:43:45+00:00 John Hawthorn john@hawthorn.email 2025-12-17T20:08:43+00:00 345ea0c8e18d3ce8fed332137d225769df619f2b Co-authored-by: Luke Gruber <luke.gru@gmail.com> 
Co-authored-by: Luke Gruber <luke.gru@gmail.com>
YJIT: Bail out if proc would be stored above stack top 2025-12-16T04:05:27+00:00 Randy Stauner randy@r4s6.net 2025-12-11T22:56:16+00:00 9168cad4d63a5d281d443bde4edea6be213b0b25 Fixes [Bug #21266]. 
Fixes [Bug #21266].
YJIT: Fix panic from overly loose filtering in identity method inlining 2025-12-13T02:23:24+00:00 Alan Wu XrXr@users.noreply.github.com 2025-12-12T23:00:18+00:00 e1f5e61d6b1b9e937a58afcae644da0917f6dd49 Credits to @rwstauner for noticing this issue in GH-15533. 
Credits to @rwstauner for noticing this issue in GH-15533.
YJIT: Add missing local variable type update for fallback setlocal blocks 2025-12-12T20:29:04+00:00 Alan Wu XrXr@users.noreply.github.com 2025-12-12T18:42:00+00:00 2884f53519c4b86072d5fc3b41a71cee697af8ba Previously, the chain_depth>0 version of setlocal blocks did not update the type of the local variable in the context. This can leave the context with stale type information and trigger panics like in [Bug #21772] or lead to miscompilation. To trigger the issue, YJIT needs to see the same ISEQ before and after environment escape and have tracked type info before the escape. To trigger in ISEQs that do not send with a block, it probably requires Kernel#binding or the use of include/ruby/debug.h APIs. 
Previously, the chain_depth>0 version of setlocal blocks did not
update the type of the local variable in the context. This can leave
the context with stale type information and trigger panics like in
[Bug #21772] or lead to miscompilation.

To trigger the issue, YJIT needs to see the same ISEQ before and after
environment escape and have tracked type info before the escape. To
trigger in ISEQs that do not send with a block, it probably requires
Kernel#binding or the use of include/ruby/debug.h APIs.
YJIT: Pass class and shape ID directly instead of object 2025-12-03T21:59:05+00:00 Max Bernstein ruby@bernsteinbear.com 2025-12-03T21:11:30+00:00 b43e66d3b37d4bd029a90dbee376e475aed79d2a 






ZJIT: Specialize String#<< with Fixnum
2025-12-01T23:19:26+00:00

Max Bernstein
ruby@bernsteinbear.com

2025-11-25T03:24:45+00:00

8aed31103874524395912fb7ffaee88b5e59a9c3

Append a codepoint.





Append a codepoint.







YJIT: Abort expandarray optimization if method_missing is defined
2025-11-26T20:56:27+00:00

Randy Stauner
randy@r4s6.net

2025-11-26T02:29:02+00:00

5f55c9c8fb8f401537e7121171747196e66c3ba0

Fixes: [Bug #21707]
[AW: rewrote comments]
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>





Fixes: [Bug #21707]
[AW: rewrote comments]
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>