August 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:126160] [Ruby Feature#22212] Add Thread::Backtrace::Location#source_range
by Eregon (Benoit Daloze) 06 Aug '26

06 Aug '26

Issue #22212 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #22212: Add Thread::Backtrace::Location#source_range https://bugs.ruby-lang.org/issues/22212 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- ## Motivation The main motivation is to be able to implement `Prism.find(Thread::Backtrace::Location)` precisely and cleanly on any Ruby implementation, in a way which does not depend on implementation details like `node_id`. For that we need the start/end line/column and the `absolute_path`, which is exactly what `Ruby::SourceRange` provides. In https://bugs.ruby-lang.org/issues/21998 we added `source_range` for `{Method,UnboundMethod,Proc}`. However we also need `source_range` for `Thread::Backtrace::Location` as this is used in `error_highlight`, `power_assert`, etc. Those tools currently use `RubyVM::AbstractSyntaxTree.node_id_for_backtrace_location(Thread::Backtrace::Location)`, however: * that's a CRuby-only experimental API * it exposes CRuby internals (`node_id`) * it adds a lot of complexity for all usages because they need to handle both `Prism::Node` and `RubyVM::AbstractSyntaxTree::Node`. We solve all of this by adding a new portable API which exposes universal concepts like line and column, which are stable to find AST nodes. ## Implementation How can we get the start/end line/column when we only keep the start line in CRuby? By re-parsing, and specifically by re-parsing with *exactly* the same parser that the interpreter used to compile to bytecode. That way there is no issue of using different Prism versions, it's the Prism C library built in CRuby, or `parse.y` in `--parser=parse.y` mode. Either way, we reparse to extract the start/end line/column. We make the returned start/end line/column match for both `Prism` and `parse.y`, in practice the only difference is for calls with blocks, where we adapt the location from parse.y to match Prism. One can then easily use Prism to get a node matching that `Ruby::SourceRange` and use the resulting `Prism::Node` as they wish. This also means all versions of Prism can be used, and for example if some dependency requires some specific version of Prism it works fine and is not a problem. As a result, the user of this API can choose the Prism version they want and always get a `Prism::Node` (and not having to handle `RubyVM::AbstractSyntaxTree::Node` too, or a duplicate `Ruby::Node` API as mentioned in #21795). PR: https://github.com/ruby/ruby/pull/18043 -- https://bugs.ruby-lang.org/

5 8

[ruby-core:126291] [Ruby Feature#9779] Add Module#descendants
by matz (Yukihiro Matsumoto) 06 Aug '26

06 Aug '26

Issue #9779 has been updated by matz (Yukihiro Matsumoto). Accepted. Let's define `Module#descendants`. This settles the question I left open in [#14394](https://bugs.ruby-lang.org/issues/14394#note-38). `Class#subclasses` already lets you write the transitive closure for classes in Ruby, but there is no equivalent primitive for modules, so `Module` is where this method actually adds something. Defining it there also gives `Class` the method for free. Not including `self` is fine too. It departs from `ancestors`, but it agrees with `Class#subclasses` and with ActiveSupport's `descendants`, and `[mod, *mod.descendants]` is available when needed. Once this is merged, I think [#14394](https://bugs.ruby-lang.org/issues/14394) can be closed. Matz. ---------------------------------------- Feature #9779: Add Module#descendants https://bugs.ruby-lang.org/issues/9779#change-118388 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- Now classes have links to their subclasses, so how about to add Module#descendents? ```ruby class X end class Y < X end class Z < Y end p X.descendents #=> [X, Y, Z] module A end module B include A end module C include A end p A.descendents #=> [A, C, B] ``` One of my own use cases is to implement AspectJ like pointcut which matches all subclasses of the given class. Considerations: * Should the return value of Module#descendents include self? * Should the return value of Module#descendents include singleton classes? I attach a patch, where the return value includes both self and singleton classes. ---Files-------------------------------- 0001-Add-Module-descendents.patch (3.75 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126165] [Ruby Feature#22213] Allow no-argument and chained calls of Proc#refined
by shugo (Shugo Maeda) 06 Aug '26

06 Aug '26

Issue #22213 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22213: Allow no-argument and chained calls of Proc#refined https://bugs.ruby-lang.org/issues/22213 * Author: shugo (Shugo Maeda) * Status: Open ---------------------------------------- ## Abstract Currently, `Proc#refined` rejects no-argument and chained calls, because I wasn't sure what the desired behavior should be. How about returning the receiver for no-argument calls: ```ruby original = -> {} refined = original.refined p refined.equal?(original) #=> true ``` and activating all the given modules for chained calls? ```ruby module M refine String do def shout = upcase + "!" end end module M2 refine Integer do def doubled = self * 2 end end original = ->(s, i) { [s.shout, i.doubled] } refined = original.refined(M).refined(M2) # the same result as original.refined(M, M2) refined.call("hi", 3) #=> ["HI!", 6] ``` ## Motivation This change is necessary to make `Proc#refined` composable. A no-argument call of `Proc#refined` is a no-op, but it's useful when the arguments are calculated at runtime: ```ruby def foo(prc, *modules) ... refined = prc.refined(*modules) ... end ``` If an empty module list were rejected, a guard like `unless modules.empty?` would be needed. A chained call of `Proc#refined` is useful to extend existing DSLs: ```ruby require "packrat_parser" require "mathn" class MathParser < PackratParser def define(sym, &block) # PackratParser#define also calls Proc#refined super(sym, &block.refined(Math::N)) end end parser = MathParser.new { ... define :multitive do [:primary, "*", :multitive].map { |x, _, y| x * y } | [:primary, "/", :multitive].map { |x, _, y| x / y } | :primary end ... } parser.parse("1 / 2") #=> (1/2) ``` ## Formal semantics With this proposal, `Proc#refined` can be formalized as a monoid action on Procs created from a block, where the acting monoid is the sequences of modules under concatenation, with the empty sequence as its unit. Writing ≃ for behavioral equivalence, the action satisfies the unit and associativity laws: ``` prc.refined ≃ prc # unit law prc.refined(*ms).refined(*ns) ≃ prc.refined(*ms, *ns) # associativity law ``` Note that the unit law holds for any Proc, since `refined` with no modules returns the receiver itself. I've written a formalization in the Rocq Prover: https://github.com/shugo/ruby-refinements-semantics It abstracts away the details irrelevant to refinements. ## Design decisions ### The receiver or a copy for no-argument calls Returning a copy was also considered, but I chose to return the receiver, following precedents such as `Data#with` and `Enumerator::Lazy#lazy`. Mutable containers tend to return a copy even for a no-op, but `Proc#refined` is closer to the former group. ### Extend or replace for chained calls If a chained call replaced the receiver's refinements instead of extending them, `prc.refined(M).refined(M2)` would activate only `M2`. That breaks the associativity law above, and makes chaining useless for the DSL case in Motivation. Extending also matches nested `using`, where refinements activated later take precedence. ## Implementation Pull request: https://github.com/ruby/ruby/pull/18052 `Proc#refined` on an already refined Proc is not memoized: the cache would be keyed on short-lived copies, and entries are retained for the VM's lifetime, so it would grow without bound. A performance warning is emitted under `Warning[:performance] = true`, and passing all the modules in a single call is more efficient. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125775] [Ruby Feature#22118] Introduce Basic Bit Operations into String
by hasumikin (hitoshi hasumi) 06 Aug '26

06 Aug '26

Issue #22118 has been reported by hasumikin (hitoshi hasumi). ---------------------------------------- Feature #22118: Introduce Basic Bit Operations into String https://bugs.ruby-lang.org/issues/22118 * Author: hasumikin (hitoshi hasumi) * Status: Open ---------------------------------------- This PR implements a subset of the specification proposed in the parent feature ticket #22082 PR URL: [placeholder to be updated] ## Methods implemented with the same specification as the parent ticket * `String#bit_at(offset, lsb_first: true) -> true | false | nil` * `String#bitwise_not -> String` * `String#bitwise_not! -> self` * `String#bitwise_and(other) -> String` * `String#bitwise_and!(other) -> self` * `String#bitwise_or(other) -> String` * `String#bitwise_or!(other) -> self` * `String#bitwise_xor(other) -> String` * `String#bitwise_xor!(other) -> self` ## Methods with range-oriented forms omitted for now The parent ticket also included range-oriented forms for some methods. In this PR, those range arguments are intentionally omitted, and the methods are limited to simpler forms. Range support can be considered as a future extension. * `String#bit_count -> Integer` * `String#bit_set(offset, lsb_first: true) -> self` * `String#bit_clear(offset, lsb_first: true) -> self` * `String#bit_flip(offset, lsb_first: true) -> self` In particular, `String#bit_count` currently takes no arguments. It does not accept a range, offset/length pair, or `lsb_first:` keyword. --- ## Remaining design questions even after narrowing the scope The overall direction of adding these methods has already been approved by Matz. The remaining questions are mostly about naming and API details. ### 1. Why the `bitwise_*` prefix is used In the parent ticket, all other methods are related to bit positions: they either take bit-position arguments, yield bit positions, or operate on a specified bit range. In contrast, the `bitwise_*` methods are whole-data operations. They apply to the entire string as a fixed-size bitmap and do not expose bit positions or bit ordering. The `bitwise_*` prefix is intended to make this distinction explicit. ### 2. Bit numbering #### `lsb_first: true` (default) Within each byte, `offset = 0` is the LSB. Numbering proceeds upward through byte[0] and then continues at the LSB of byte[1]: ```text byte[0] byte[1] offset: 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 bit: b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 ^ ^ LSB LSB offset = byte_index * 8 + bit_in_byte ``` #### `lsb_first: false` for MSB-first Byte order is preserved (`byte[0]` is still first), but within each byte numbering starts at the MSB: ```text byte[0] byte[1] offset: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 bit: b7 b6 b5 b4 b3 b2 b1 b0 b7 b6 b5 b4 b3 b2 b1 b0 ^ ^ MSB MSB offset = byte_index * 8 + (7 - bit_in_byte) ``` * Whether `lsb_first:` is needed at all, or whether an equivalent mechanism should exist under another name? * If such a mechanism is needed, whether `lsb_first:` is the right keyword name? * If `lsb_first:` is acceptable, should its default be `true`? My point is that `lsb_first:` is needed because both bit numbering conventions are used in real byte-buffer formats. LSB-first is the more common convention for general in-memory bitmap use, including formats and APIs such as Apache Arrow validity bitmaps, ext4 block bitmaps, Roaring bitmaps, Linux/BSD bitmap APIs, and hardware register descriptions. MSB-first is also needed for domains such as RFC-style network protocol diagrams, PNG low-bit-depth scanlines, BitTorrent bitfields, and some compressed bit streams. The keyword only controls bit numbering within each byte. Byte order itself is unchanged. ### 3. Out-of-range behavior `String#bit_at` returns `nil` when the bit offset is out of range. On the other hand, mutating methods such as `String#bit_set`, `String#bit_clear`, and `String#bit_flip` raise `IndexError` for an out-of-range bit offset. This follows the same general distinction as read-like access versus write-like access: reading a missing position can return `nil`, but mutating a missing position should not silently do nothing. ### 4. Negative bit offsets Negative bit offsets are rejected with `IndexError`. Although Ruby often uses negative indices to count from the end, combining negative bit offsets with the `lsb_first: true/false` mechanism would make the numbering rule harder to explain and reason about. The API keeps bit offsets as non-negative flat positions from the beginning of the string. ### 5. Length mismatch for binary bitwise operations `String#bitwise_and`, `String#bitwise_or`, and `String#bitwise_xor` require both operands to have the same byte size. If the byte sizes differ, they raise `ArgumentError`. This avoids implicit truncation or zero-padding. Since these methods operate on strings as fixed-size bitmaps, requiring equal sizes makes the operation explicit and predictable. -- https://bugs.ruby-lang.org/

5 9

[ruby-core:126227] [Ruby Bug#22225] YJIT regenerates a branch while a duplicate target still points to the invalidated block
by cosgroveb (Brian Cosgrove) 05 Aug '26

05 Aug '26

Issue #22225 has been reported by cosgroveb (Brian Cosgrove). ---------------------------------------- Bug #22225: YJIT regenerates a branch while a duplicate target still points to the invalidated block https://bugs.ruby-lang.org/issues/22225 * Author: cosgroveb (Brian Cosgrove) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-03T03:11:21Z master f622e12503) +YJIT dev +PRISM [aarch64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- YJIT adds one incoming-list entry for each branch target that points to a block. When both targets point to the same block, that block's incoming list contains the same `BranchRef` twice. `invalidate_block_version` processes those entries separately. For the first entry, it redirects one target and immediately calls `regenerate_branch`. The other target still references the invalidated block. The following assertion fails immediately before that call: ```patch diff --git a/yjit/src/core.rs b/yjit/src/core.rs index d08cd1fb26..4555081ae2 100644 --- a/yjit/src/core.rs +++ b/yjit/src/core.rs @@ -4282,6 +4282,18 @@ pub fn invalidate_block_version(blockref: &BlockRef) { } } + assert!( + branch.targets.iter().all(|target| unsafe { + // SAFETY: no mutation. + target + .ref_unchecked() + .as_ref() + .and_then(|target| target.get_block()) + != Some(*blockref) + }), + "regeneration started while a branch target still referenced the invalidated block" + ); + // Rewrite the branch with the new jump target address let old_branch_size = branch.code_size(); regenerate_branch(cb, branch); ``` This Ruby script triggers the assertion: ```ruby # duplicate_target_invalidation.rb module DuplicateTargetInvalidation TARGET = 1 def self.call(condition) if condition 1 else 2 end TARGET end end 3.times do |index| DuplicateTargetInvalidation.call(index.even?) end DuplicateTargetInvalidation.send(:remove_const, :TARGET) puts "completed" ``` Save the patch as `assert-no-invalidated-target-before-regeneration.patch` and the script as `duplicate_target_invalidation.rb`. From CRuby `ruby 4.1.0dev`: ```sh git apply assert-no-invalidated-target-before-regeneration.patch ./autogen.sh mkdir build cd build ../configure --enable-yjit=dev make -j"$(nproc)" ./ruby --yjit-call-threshold=1 ../duplicate_target_invalidation.rb ``` The process aborts before printing `completed`: ```text [BUG] YJIT: panicked at yjit/src/core.rs:4285:9: regeneration started while a branch target still referenced the invalidated block ``` regenerate_branch runs with one target redirected to a stub and the other still pointing at the invalidated block. That can leave generated code jumping back into code YJIT just invalidated. -- https://bugs.ruby-lang.org/

3 8

[ruby-core:126246] [Ruby Bug#22228] Do a major GC in YJIT test helper `assert_compiles` before running the test code
by jprokop (Jarek Prokop) 04 Aug '26

04 Aug '26

Issue #22228 has been reported by jprokop (Jarek Prokop). ---------------------------------------- Bug #22228: Do a major GC in YJIT test helper `assert_compiles` before running the test code https://bugs.ruby-lang.org/issues/22228 * Author: jprokop (Jarek Prokop) * Status: Open * ruby -v: ruby 4.1.0dev (2026-08-04T15:30:26Z master 036159508e) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I was debugging why a YJIT test added from backport to 3.3.11 with GC.stress fails downstream. This revealed an assumption in the assert_compiles, that the environment is "clean", or as default as possible. `assert_compiles` already sanitizes environment with `--disable-gems` and `reset_stats!` call. I'd like to propose the `assert_compiles` method to trigger a GC.start before executing the test proc, and before the stats reset. While the issue described below does not happen on default Rubies 3.4 and 4.0, it could enhance the YJIT test environment. I was investigating downstream test failure on Ruby 3.3.11 (and later 3.3.12) [0] that appeared after backport of: https://bugs.ruby-lang.org/issues/21266 Where the tests in YJIT expects no exits by default: Provided as a default here: https://github.com/ruby/ruby/blob/3e646aee/test/ruby/test_yjit.rb#L2015 Expected as part of condition here: https://github.com/ruby/ruby/blob/3e646aee/test/ruby/test_yjit.rb#L2080 Downstream we insert hook for optional ABRT error reporting for Ruby: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad5… Relevant patchfile: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad5… We create empty `abrt.rb` to test with later on: https://src.fedoraproject.org/rpms/ruby/blob/11eb00c7bf5c87033a73301ca8dad5… To reproduce the failure in 3.3, both the patch and the file are required to exist for the failure at [0] to appear. Later I found that parse.y opens a file to load the abrt.rb and registers it with Ruby GC, which causes zombie and interrupt on `GC.stress=true`, since prism parser became default, these failures no longer appear as the parser does not copy parse.y's approach of registering the opened file with Ruby GC. The note on #19921 https://bugs.ruby-lang.org/issues/19921#note-20 regarding this was correct and it's also the earliest known appearance of the issue. --- [0] Test failure result: TestYJIT#test_proc_block_with_kwrest = 0.08 s 1) Failure: TestYJIT#test_proc_block_with_kwrest [/builddir/build/BUILD/ruby-3.3.11/test/ruby/test_yjit.rb:1531]: Expected no exits, but got: {:send=>1} Reasons: method call fallback reasons: iseq_has_kwrest: 1 (100.0%) invokeblock fallback reasons: proc: 2 (100.0%) invokesuper fallback reasons: (all relevant counters are zero) method call exit reasons: interrupted: 1 (100.0%) invokeblock exit reasons: (all relevant counters are zero) invokesuper exit reasons: (all relevant counters are zero) getblockparamproxy exit reasons: (all relevant counters are zero) getinstancevariable exit reasons: (all relevant counters are zero) setinstancevariable exit reasons: (all relevant counters are zero) leave exit reasons: interp_return: 6 (100.0%) left shift (ltlt) exit reasons: (all relevant counters are zero) invalidation reasons: constant_ic_fill: 2 (100.0%) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126237] [Ruby Bug#18947] Unexpected Errno::ENAMETOOLONG on Windows
by hsbt (Hiroshi SHIBATA) 04 Aug '26

04 Aug '26

Issue #18947 has been updated by hsbt (Hiroshi SHIBATA). Two questions before this goes further. * The bit is set in `rb_w32_sysinit`, so only hosts that call `ruby_sysinit` get it, which effectively means `ruby.exe`. Embedders that do their own initialization keep the 260 character limit. Should I move it somewhere every embedder reaches? * `IsLongPathAwareProcess` is undocumented. golang has set it since 1.23, but Microsoft's Go maintainers proposed removing it. The alternative is `\\?\` prefixing at about 15 call sites, which still cannot fix `Dir.chdir` or `require`. ---------------------------------------- Bug #18947: Unexpected Errno::ENAMETOOLONG on Windows https://bugs.ruby-lang.org/issues/18947#change-118323 * Author: inversion (Yura Babak) * Status: Open * Assignee: windows * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x64-mingw-ucrt] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- On Windows 10, I am working on a script to copy a complex folder structure. Pathname and FileUtils work fine for me until there is a folder with a **very long path** (>260 chars). Normally you cannot access such a folder with Ruby. The next operations will raise `Errno::ENOENT` ``` ruby Pathname.new(300_chars_path).children FileUtils.mkpath(300_chars_path) ``` But there is a way in Windows to remove the MAX_PATH limitation. You can find a small .reg file in this article: https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-lim… After changing this system option, things start to work strangely in Ruby. This will now raise `Errno::ENAMETOOLONG`: ``` ruby Pathname.new(300_chars_path).children ``` But at the same time, you can create a folder with such a long path and write-read a file in it ``` ruby FileUtils.mkpath(300_chars_path) file = Pathname.new(300_chars_path+'/file.txt') file.write 'oooooooooo' puts Pathname.new(300_chars_path+'/file.txt').read ``` So you can work with individual items but attempts to list such folders' content fail (`.children`, `.glob`, `.copy`, etc). In my case, deep `.glob` is broken for all the parent folders of that deep long-path folder (( The only way I found for listing is ``` ruby require 'win32ole' fso = WIN32OLE.new 'Scripting.FileSystemObject' for file in fso.GetFolder(300_chars_path).files file.name file.path.length end ``` But using this workaround breaks all my code workflow built on top of Pathname and FileUtils ((. So for me, it looks like some operations with long-path folders are not working just because in Ruby there is a check for the path length and not a real operation problem. And in some places (see .mkpath) there is no such check and all works fine. Also notice that other applications on Windows have no problems with long-path folders (like Total Commander). Please consider reviewing if we really need to raise `Errno::ENAMETOOLONG` if the `LongPathsEnabled` option is enabled in the Windows registry. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126226] [Ruby Bug#22224] YJIT: rb_yjit_invalidate_ep_is_bp takes the VM lock stopping Ractors on every Proc materialization; multi-Ractor throughput collapses (up to ~150x)
by yaroslavmarkin (Yaroslav Markin) 03 Aug '26

03 Aug '26

Issue #22224 has been reported by yaroslavmarkin (Yaroslav Markin). ---------------------------------------- Bug #22224: YJIT: rb_yjit_invalidate_ep_is_bp takes the VM lock stopping Ractors on every Proc materialization; multi-Ractor throughput collapses (up to ~150x) https://bugs.ruby-lang.org/issues/22224 * Author: yaroslavmarkin (Yaroslav Markin) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hi! Fair warning: a significant portion of this bugreport and experimentation/benchmarking was done by an agent. Sorry for the slop, but it was so much faster to benchmark and find a root issue. ## Summary With YJIT enabled, `vm_make_env_each` calls `rb_yjit_invalidate_ep_is_bp` on every Proc/lambda environment materialization. That function enters `with_vm_lock` unconditionally (the only early return covers boot, before `INVARIANTS` is initialized). In multi-Ractor mode this lock acquisition is `rb_jit_vm_lock_then_barrier`: the VM lock plus a stop-all-Ractors barrier. The result: any workload that creates Procs loses parallel scalability under Ractors, and beyond ~2 Ractors adding workers makes the whole process slower in absolute terms. In the repro below, 8 Ractors with YJIT run ~150x slower than 1 Ractor with YJIT, and ~195x slower than 8 Ractors without YJIT, on the same code. Note the invalidation itself is not the cost. After the first escape of a given iseq, its `no_ep_escape_iseqs` entry is an empty set forever (`ep_is_bp()` returns false for it, so no new blocks are ever registered), yet every subsequent materialization still pays lock + global barrier to look up the entry and iterate nothing. ## Standalone repro (no gems) ```ruby # Usage: ruby [--yjit] yjit_ractor_repro.rb [proc|calc] [n_ractors] [seconds] MODE = (ARGV[0] || "proc").to_sym N = (ARGV[1] || 1).to_i DUR = (ARGV[2] || 3).to_f def make_proc(i) x = i -> { x + 1 } # captures x: the frame env is materialized on every call end def work_proc(n) s = 0 n.times { |i| s += make_proc(i).call } s end def work_calc(n) s = 0 n.times { |i| s += (i * i) % 7 } # same shape, no Proc escapes s end def bench_loop(mode, dur) count = 0 deadline = Process.clock_gettime(Process::CLOCK_MONOTONIC) + dur while Process.clock_gettime(Process::CLOCK_MONOTONIC) < deadline mode == :proc ? work_proc(1000) : work_calc(1000) count += 1000 end count end bench_loop(MODE, 0.5) # warm up: get the methods YJIT-compiled before measuring total = if N == 1 bench_loop(MODE, DUR) else N.times.map { Ractor.new(MODE, DUR) { |m, d| bench_loop(m, d) } }.sum(&:value) end puts format("mode=%s yjit=%s ractors=%d throughput=%.2fM iters/s", MODE, RubyVM::YJIT.enabled?, N, total / DUR / 1_000_000.0) ``` Results on Apple M1 Pro (10 cores), macOS, `ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [arm64-darwin25]`, 3 s per cell: | workload | ractors | interpreter (M iters/s) | --yjit (M iters/s) | |----------|---------|-------------------------|--------------------| | calc (control, no Proc) | 1 | 21.3 | 129.4 | | calc | 4 | 83.0 | 495.3 | | calc | 8 | 162.2 | **969.1** | | proc | 1 | 4.5 | 6.0 | | proc | 4 | 7.7 | **0.14** | | proc | 8 | 7.8 | **0.04** | The control shows this is not a general YJIT-vs-Ractor problem: on the Proc-free workload YJIT scales superbly (969M iters/s at 8 Ractors). Only the environment-materializing workload collapses, and only with YJIT on. ## Where the time goes Native sampling (macOS `sample`) of a loaded multi-Ractor process shows almost all threads parked in `__psynch_cvwait`, with the barrier initiated from: ``` vm_make_env_each -> rb_yjit_invalidate_ep_is_bp (yjit/src/invariants.rs) -> with_vm_lock -> rb_jit_vm_lock_then_barrier -> rb_ractor_sched_barrier_start (victims: rb_ractor_sched_barrier_join / ractor_sched_barrier_join_wait_locked) ``` In a 6 s sample of a 5-Ractor process, barrier-related frames appear ~9,000 times vs ~50 in the single-Ractor run of the same workload. Ruby-side profilers cannot see this: the wait time is attributed as diffuse "self time" across whatever frames are on top, which is presumably why it has gone unreported. Current code (`yjit/src/invariants.rs`, same on master as of 2026-08-03): ```rust pub extern "C" fn rb_yjit_invalidate_ep_is_bp(iseq: IseqPtr) { // Skip tracking EP escapes on boot. We don't need to invalidate anything during boot. if unsafe { INVARIANTS.is_none() } { return; } with_vm_lock(src_loc!(), || { let no_ep_escape_iseqs = &mut Invariants::get_instance().no_ep_escape_iseqs; match no_ep_escape_iseqs.get_mut(&iseq) { Some(blocks) => { for block in mem::take(blocks) { invalidate_block_version(&block); incr_counter!(invalidate_ep_escape); } } None => { no_ep_escape_iseqs.insert(iseq, HashSet::new()); } } }); } ``` ## Real-world impact Rails 8.1 enables YJIT by default, and a Rails request materializes many Proc environments (middleware blocks, route handling, view rendering), so any Rails app served by a multi-Ractor server hits this out of the box. Found while investigating https://github.com/yaroslav/kino/issues/6, where a stock Rails 8.1 app showed worker scaling inverting: more Ractors, less total throughput. Rails 8.1.3 health-check endpoint (`/up`, no database), `ab -c 64 -k`, kino `:ractor` mode, N workers x 1 thread, requests/sec: | workers | YJIT on (Rails default) | YJIT off | |---------|-------------------------|----------| | 1 | 6,416 | 3,964 | | 2 | 5,036 | 6,999 | | 5 | 2,800 | 13,269 | | 8 | 2,003 | 12,596 | Fully disabling GC changed the YJIT-on numbers by only ~7%, ruling out GC barriers as the driver; the native profile above identifies the initiator. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126201] [Ruby Bug#22220] Performance regression when requiring `aws-sdk-ec2` in Ruby 4.0.6
by emanuelevans (Emanuel Evans) 03 Aug '26

03 Aug '26

Issue #22220 has been reported by emanuelevans (Emanuel Evans). ---------------------------------------- Bug #22220: Performance regression when requiring `aws-sdk-ec2` in Ruby 4.0.6 https://bugs.ruby-lang.org/issues/22220 * Author: emanuelevans (Emanuel Evans) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Ruby 4.0.6 introduced a large performance regression when loading `aws-sdk-ec2` (~30s on my machine, compared to <1s for ruby 4.0.5). Script to reproduce: ``` for v in 4.0.5 4.0.6; do docker run --rm ruby:$v-slim bash -c ' gem install --no-document aws-sdk-ec2 -v 1.402.0 >/dev/null 2>&1 ruby -e "t = Process.clock_gettime(Process::CLOCK_MONOTONIC) require \"aws-sdk-ec2\" printf(\"ruby %s: %.2fs\n\", RUBY_VERSION, Process.clock_gettime(Process::CLOCK_MONOTONIC) - t)"' done ``` It appears to be related to `Shape.new` and/or `Class.new` compile times; minimal reproduction: ``` for v in 4.0.5 4.0.6; do docker run --rm ruby:$v-slim ruby -e ' src = "class Shape\n def self.new(**) = nil\nend\nmodule M\n" + (1..16_000).map { |i| %( K_#{i} = Shape.new(name: "k#{i}")) }.join("\n") + "\nend\n" File.write("/tmp/bench.rb", src) t = Process.clock_gettime(Process::CLOCK_MONOTONIC) RubyVM::InstructionSequence.compile_file("/tmp/bench.rb") printf("ruby %s: %.2fs\n", RUBY_VERSION, Process.clock_gettime(Process::CLOCK_MONOTONIC) - t)' done ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:115016] [Ruby master Bug#19921] TestYJIT#test_bug_19316 test failure
by vo.x (Vit Ondruch) 03 Aug '26

03 Aug '26

Issue #19921 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #19921: TestYJIT#test_bug_19316 test failure https://bugs.ruby-lang.org/issues/19921 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-12 master 52709a4862) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Testing with 52709a4862 on Fedora Rawhide, I observe following failure: ~~~ 94) Failure: TestYJIT#test_bug_19316 [/builddir/build/BUILD/ruby-3.3.0-52709a4862/test/ruby/test_yjit.rb:1126]: Expected no exits, but got {:opt_and=>1} ~~~ -- https://bugs.ruby-lang.org/

6 21