ruby.git/yjit, 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>
JITs: Pass down GNU make jobserver resources when appropriate 2025-12-17T19:49:32+00:00 Alan Wu XrXr@users.noreply.github.com 2025-12-17T18:51:12+00:00 656de67d5c8cd894eeda0baa618663098dce17f2 To fix warnings from rustc on e.g. Make 4.3, which is in Ubuntu 24.04: > warning: failed to connect to jobserver from environment variable 
To fix warnings from rustc on e.g. Make 4.3, which is in Ubuntu 24.04:

> warning: failed to connect to jobserver from environment variable
YJIT: Print `Rc` strong and weak count on assert failure 2025-12-16T19:56:40+00:00 Alan Wu XrXr@users.noreply.github.com 2025-12-16T18:33:47+00:00 eaa952b536c48658a5a2e3f128e3afdef03a01b6 For <https://bugs.ruby-lang.org/issues/21716>, the panic is looking like some sort of third party memory corruption, with YJIT taking the fall. At the point of this assert, the assembler has dropped, so there's nothing in YJIT's code other than JITState that could be holding on to these transient `PendingBranchRef`. The strong count being more than a handful or the weak count is non-zero shows that someone in the process (likely some native extension) corrupted the Rc's counts. 
For <https://bugs.ruby-lang.org/issues/21716>, the panic is looking like
some sort of third party memory corruption, with YJIT taking the fall.
At the point of this assert, the assembler has dropped, so there's
nothing in YJIT's code other than JITState that could be holding on to
these transient `PendingBranchRef`.

The strong count being more than a handful or the weak count is non-zero
shows that someone in the process (likely some native extension)
corrupted the Rc's counts.
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.
JITs: Drop cargo and use just rustc for release combo build 2025-12-10T21:35:00+00:00 Alan Wu XrXr@users.noreply.github.com 2025-12-09T03:25:05+00:00 029a48176cf9fd367d52d8c9f87cb9f77d425a43 So we don't expose builders to network flakiness which cannot be worked around using cargo's --offline flag. 
So we don't expose builders to network flakiness which cannot be worked
around using cargo's --offline flag.