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

[ruby-core:124342] [Ruby Feature#21800] `Dir.foreach` and `Dir.each_child` to optionally yield `File::Stat` object alongside the children name
by byroot (Jean Boussier) 21 Oct '26

21 Oct '26

Issue #21800 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21800: `Dir.foreach` and `Dir.each_child` to optionally yield `File::Stat` object alongside the children name https://bugs.ruby-lang.org/issues/21800 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- When listing a directory, it's very common to need to know the type of each children, generally because you want to scan recursively. The naive way to do this is to call `stat(2)` for each children, but this is quite costly. This use case is common enough that `readdir` on most modern platforms do expose `struct dirent.d_type`, which allows to know the type of the child without an extra syscall. I wrote a quick prototype, and relying on `dirent.d_type` instead of `stat(2)` allows to recursively scan Ruby's repository twice as fast on my machine: https://github.com/ruby/ruby/pull/15667 Given that recursively scanning directories is a common task across many popular ruby tools (`zeitwerk`, `rubocop`, etc), I think it would be very valuable to provide this more efficient interface. In addition, @nobu noticed my prototype, and implemented a nicer version of it, where a `File::Stat` is yielded: https://github.com/ruby/ruby/commit/9acf67057b9bc6f855b2c37e41c1a2f91eae643a In that case the `File::Stat` is lazy, it's only if you access something other than file type, that the actual `stat(2)` call is emitted. I think this API is both more efficient and more convenient. ### Proposed API ```ruby Dir.foreach(path) { |name| } Dir.foreach(path) { |name, stat| } Dir.each_child(path) { |name| } Dir.each_child(path) { |name| } Dir.new(path).each_child { |name, stat| } Dir.new(path).each_child { |name, stat| } Dir.new(path).each { |name, stat| } Dir.new(path).each { |name, stat| } ``` Also important to note, the `File::Stat` is expected to be equivalent to a `lstat(2)` call, as to be able to chose to follow symlinks or not. Basic use case: ```ruby def count_ruby_files(root) count = 0 queue = [root] while dir = queue.pop Dir.(dir) do |name, stat| next if name.start_with?(".") if stat.directory? queue << File.join(dir, name) elsif stat.file? count += 1 if name.end_with?(".rb") end end end count end ``` -- https://bugs.ruby-lang.org/

6 11

[ruby-core:127168] [Ruby Bug#22453] GET_EC() may break when the native thread switches under M:N threads
by mame (Yusuke Endoh) 21 Oct '26

21 Oct '26

Issue #22453 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #22453: GET_EC() may break when the native thread switches under M:N threads https://bugs.ruby-lang.org/issues/22453 * Author: mame (Yusuke Endoh) * Status: Open * Assignee: ko1 (Koichi Sasada) * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- There are many bugs caused by the bad interaction between the M:N thread model and `GET_EC()`. A simple example is code that switches the native thread inside a block of `String#split`. ```ruby 8.times.map do Ractor.new do 50.times do ",,".split(/(,)/) { sleep 0.001 } end :ok end end.map(&:value) ``` When Ruby is built with Clang 21, this causes a segmentation fault: ``` $ ./build-clang21/miniruby 31_string_split.rb 31_string_split.rb:2: warning: Ractor API is experimental and may change in future versions of Ruby. 31_string_split.rb:4: [BUG] Segmentation fault at 0x0000000000000030 ruby 4.1.0dev (2026-10-14T18:01:17Z master 90a3551c8a) +PRISM [x86_64-linux] ``` I had Claude Code analyze the problem, and it found 32 similar bugs (listed at the end). I believe there are many more. ## Cause The cause is a bad interaction between C compiler optimizations and the M:N thread model. A C compiler may optimize code assuming that the native thread does not change during the execution of a function. For an access to a variable stored in Thread-local Storage (TLS), it may cache the pointer to the variable in the function and generate code that dereferences the cached pointer in later accesses. On the other hand, under the M:N thread model, the native thread may change in the middle of the execution of a C function. So, if the native thread switches after the pointer is cached, the pointer still points to the old TLS, and dereferencing it may cause a SEGV or other failures. In the `String#split` example above, `str_alloc_embed` is inlined into `rb_str_split_m`, and the TLS address used by `GET_EC()` in it is cached. Then, when `sleep 0.001` in the block of `split` switches the native thread, the invalid address is dereferenced. This problem has already been reported in #20243, #21046, #21534, #22440 and others, but it has been addressed by fixing individual places or by workarounds for specific platforms. However, with newer compilers such as GCC 16 and Clang 21, I have confirmed that it happens in many places on x86-64. ## How to fix There are two options. 1. Avoid `GET_EC()` as much as possible and pass `ec` explicitly. 2. Make `rb_current_ec()` NOINLINE so that the compiler cannot cache the TLS address. I think option 1 is not realistic because it requires rewriting a large amount of existing code. Option 2 is already applied on arm64 and ppc64le (https://github.com/ruby/ruby/blob/61d31c4d2b956e1bf7fc09cced93ad20d9c5c81c/…) I propose to apply it unconditionally. PR: https://github.com/ruby/ruby/pull/19421 With this change, none of the 32 reproducers reproduce anymore. ## Performance The concern with NOINLINE is performance, so I measured it. Some cases get slower and others get faster. Overall, I think the impact is small. Change in execution time from before to after the patch (median of 20 runs; negative means faster): | Benchmark | GCC 16 | Clang 21 | |---|---|---| | alloc (`Object.new`) | -0.4% | +0.0% | | method (method call) | -0.9% | +0.4% | | block (`yield`) | -1.1% | -1.4% | | cfunc (`Array#size` etc.) | -0.8% | +1.5% | Environment: AMD Ryzen 9 6900HX, Ubuntu, source at 90a3551c8a, built with --enable-shared. ## Reproducers ### 1. `rb_f_raise` ```ruby class E < StandardError def exception(*) = (sleep 0.001; self) end 8.times.map { Ractor.new { 50.times { raise E.new rescue nil } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000010 (GCC 16) ``` ### 2. `fiber_initialize` ```ruby class H < Hash def initialize_copy(*) = (sleep 0.001; super) end 8.times.map { Ractor.new { 50.times { Fiber.new(storage: H.new) {}.resume } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 3. `nurat_convert` ```ruby class N def to_int = (sleep 0.001; 3) end 8.times.map { Ractor.new { 25.times { Rational(N.new, N.new) } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 4. `f_complex_polar_real` ```ruby class N < Numeric def real? = true def coerce(o) = [self, self] def to_f = 1.0 def *(o) = (sleep 0.001; 2) def +(o) = 3 end 8.times.map { Ractor.new { 25.times { Complex.polar(N.new, 2) } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 5. `nurat_rationalize` ```ruby class Eps < Numeric def real? = true def abs = self def zero? = false def coerce(o) = (sleep 0.001; [o, 1r / 1_000_000_000]) end 8.times.map { Ractor.new { 25.times { (3r / 7).rationalize(Eps.new) } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 6. `rb_complex_uminus` ```ruby class A < Numeric def real? = true def -@ = self def -(o) = (sleep 0.001; 5) end class B < Numeric def real? = true def -@ = Complex(1, 2) end 8.times.map { Ractor.new { 50.times { -Complex.rect(A.new, B.new) } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 7. `rb_complex_conjugate` ```ruby class A < Numeric def real? = true def -@ = self def -(o) = (sleep 0.001; 5) end class B < Numeric def real? = true def -@ = Complex(1, 2) end 8.times.map { Ractor.new { 50.times { Complex.rect(A.new, B.new).conjugate } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 8. `rb_complex_pow` ```ruby class Z < Numeric def ==(o) = (sleep 0.001; true) end 8.times.map { Ractor.new { 50.times { Complex(1, 2) ** Z.new } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 9. `rb_complex_pow (complex_pow_for_special_angle)` ```ruby class N < Numeric def real? = true def <(o) = (sleep 0.001; true) def -@ = 3 end 8.times.map { Ractor.new { 50.times { Complex.rect(N.new, 0) ** 2 } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 10. `f_muldiv` ```ruby 4.times.map do |i| Ractor.new(i) do |i| q = Rational(7**3000 + i, 3**1500 + 1) t = Time.now 2.times.map { Thread.new { q.round(5) while Time.now - t < 0.5 } }.each(&:join) end end.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 11. `exec_recursive` ```ruby class Slow def inspect = (sleep 0.001; raise "boom") end 8.times.map { Ractor.new { 50.times { [Slow.new].inspect rescue nil } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000010 (GCC 16, Clang 21) ``` ### 12. `exec_recursive (outermost)` ```ruby class SlowKey def hash = (sleep 0.001; raise "boom") end 8.times.map { Ractor.new { h = {}; 50.times { (h[SlowKey.new] = 1) rescue nil } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000010 (GCC 16, Clang 21) ``` ### 13. `rb_thread_sleep_deadly` ```ruby class Ping < StandardError; end 8.times.map do Ractor.new do finished = false sleeper = Thread.new do until finished begin Thread.handle_interrupt(Object => :never) { Thread.stop } rescue Ping end end end Thread.new do t_end = Time.now + 0.05 while Time.now < t_end 5.times { sleeper.raise(Ping) rescue nil; sleep 0.0005 } sleeper.wakeup rescue nil sleep 0.002 end finished = true end.join sleeper.wakeup rescue nil until sleeper.join(0.001) end end.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 14. `mutex_lock_uninterruptible` ```ruby class Ping < StandardError; end 8.times.map do Ractor.new do m = Mutex.new cv = ConditionVariable.new finished = false sleeper = Thread.new do until finished begin Thread.handle_interrupt(Object => :never) { m.synchronize { cv.wait(m) } } rescue Ping end end end Thread.new do t_end = Time.now + 0.05 while Time.now < t_end m.synchronize do cv.signal 5.times { sleeper.raise(Ping) rescue nil; sleep 0.0005 } end sleep 0.002 end finished = true end.join m.synchronize { cv.broadcast } until sleeper.join(0.001) end end.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 15. `gc_finalize_deferred` ```ruby 8.times.map do Ractor.new do 10.times do 4.times { ObjectSpace.define_finalizer(Object.new, proc { sleep 0.0005 }) } GC.start sleep 0.0001 end end end.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000024 (GCC 16, Clang 21) ``` ### 16. `rb_str_times` ```ruby class N def to_int = (sleep 0.001; 3) end 8.times.map { Ractor.new { 50.times { "ab" * N.new } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000010 (GCC 16, Clang 21) ``` ### 17. `rb_const_search_from` ```ruby 50.times do |i| path = File.expand_path("nt_switch_autoload_#{i}.rb") File.write(path, "sleep 0.001\n") # does not define the constant autoload :"C#{i}", path end 8.times.map { Ractor.new { 50.times { |i| Object.const_get(:"C#{i}") rescue nil } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000098 (GCC 16) ``` ### 18. `rb_to_int` ```ruby class N def to_int = (sleep 0.001; 3) end 8.times.map { Ractor.new { 50.times { [1, 2, 3, 4].first(N.new) } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000010 (GCC 16, Clang 21) ``` ### 19. `rb_check_integer_type` ```ruby class N def to_int = (sleep 0.001; 3) end 8.times.map { Ractor.new { 50.times { "abc".byteslice(N.new) } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000010 (GCC 16, Clang 21) ``` ### 20. `rb_f_integer1` ```ruby class N def to_i = (sleep 0.001; 3) end 8.times.map { Ractor.new { 50.times { Integer(N.new) } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000010 (GCC 16, Clang 21) ``` ### 21. `nucomp_s_new` ```ruby class N < Numeric def real? = (sleep 0.001; true) end 8.times.map { Ractor.new { 50.times { Complex.rect(N.new) rescue nil } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 22. `nucomp_s_polar` ```ruby class N < Numeric def real? = (sleep 0.001; true) end 8.times.map { Ractor.new { 50.times { Complex.polar(N.new) rescue nil } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (GCC 16) ``` ### 23. `detach_process_watcher` ```ruby 8.times.map do Ractor.new do 10.times do ths = 2.times.map { Process.detach(Process.spawn("sleep", "0.001")) } ths.each { raise "bad #{it.value.inspect}" unless Process::Status === it.value } end end end.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (Clang 21) ``` ### 24. `proc_waitall` ```ruby 8.times.map do Ractor.new do 12.times do 4.times { Process.spawn("sleep", "0.001") } 2.times.map { Thread.new { Process.waitall } }.each(&:join) end end end.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (Clang 21) ``` ### 25. `rb_thread_io_close_wait` ```ruby 12.times.map do Ractor.new do 100.times do r, w = IO.pipe ths = 8.times.map { Thread.new { r.read rescue nil } } Thread.pass until ths.all? { it.status == "sleep" } r.close ths.each(&:join) w.close end end end.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (Clang 21) ``` ### 26. `rb_error_frozen_object` ```ruby class F def self.to_s = (sleep 0.001; "F") def self.inspect = (sleep 0.001; "F") end 8.times.map do Ractor.new do 50.times do F.new.freeze.instance_variable_set(:@a, 1) rescue FrozenError end end end.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000010 (Clang 21) ``` ### 27. `rb_ary_permutation` ```ruby 8.times.map { Ractor.new { 12.times { n = 0; [*0...200].permutation(200) { sleep 0.001; break if (n += 1) > 5 } } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (Clang 21) ``` ### 28. `rb_ary_repeated_combination` ```ruby 8.times.map { Ractor.new { 12.times { n = 0; [1, 2].repeated_combination(200) { sleep 0.001; break if (n += 1) > 5 } } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (Clang 21) ``` ### 29. `rb_ary_repeated_permutation` ```ruby 8.times.map { Ractor.new { 12.times { n = 0; [1, 2].repeated_permutation(200) { sleep 0.001; break if (n += 1) > 5 } } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (Clang 21) ``` ### 30. `rb_ary_transpose` ```ruby class A def initialize(slow) = @slow = slow def to_ary = (sleep 0.001 if @slow; [1, 2, 3]) end 8.times.map { Ractor.new { 2.times { Array.new(200) { A.new(it == 0) }.transpose } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (Clang 21) ``` ### 31. `rb_str_split_m` ```ruby 8.times.map { Ractor.new { 12.times { ",,".split(/(,)/) { sleep 0.001 } } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (Clang 21) ``` ### 32. `ruby_float_step` ```ruby 8.times.map { Ractor.new { 12.times { 1e300.step(2e300, 2e299) { sleep 0.001 } } } }.each(&:join) #=> [BUG] Segmentation fault at 0x0000000000000030 (Clang 21) ``` -- https://bugs.ruby-lang.org/

3 8

[ruby-core:127191] [Ruby Bug#22460] Ractor crash, shared arrays
by kddnewton (Kevin Newton) 21 Oct '26

21 Oct '26

Issue #22460 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #22460: Ractor crash, shared arrays https://bugs.ruby-lang.org/issues/22460 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I'm sorry I have no idea what is going on with this, but this crashes: ```ruby a = Array.new(200, 0) b = a.pop(150) a << 0 b.freeze Ractor.shareable?(b) ``` Replacing `pop` with `slice!` fixes it, if that helps. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127189] [Ruby Bug#22458] `Time#strftime` out-of-bound access
by nobu (Nobuyoshi Nakada) 21 Oct '26

21 Oct '26

Issue #22458 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22458: `Time#strftime` out-of-bound access https://bugs.ruby-lang.org/issues/22458 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- This code crashes: ```ruby Time.at(0, in: 0).strftime("%2147483647:::z") ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127184] [Ruby Bug#22457] Implicit Ractor shareability for frozen objects is buggy
by luke-gru (Luke Gruber) 20 Oct '26

20 Oct '26

Issue #22457 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Bug #22457: Implicit Ractor shareability for frozen objects is buggy https://bugs.ruby-lang.org/issues/22457 * Author: luke-gru (Luke Gruber) * Status: Open * Assignee: ractor * Target version: 4.1 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Background To share objects between Ractors without passing them explicitly with `Ractor#send`, you can use shareable objects. Certain objects are always shareable (such as nil, true, false, Symbols, etc) but most aren't. To make an objects shareable, you can use `Ractor.make_shareable`. This freezes the object recursively and makes it possible to be shared across Ractors. To make it easier for developers, we also made it possible to just `#freeze` your object, and if your object passes all shareability rules (all its references are also frozen), then it can also be shared. For example: ```ruby ALPHA = [:A, :B, :C].freeze r = Ractor.new do puts ALPHA # this works, it can be accessed end.join ``` On the other hand, this results in an error: ```ruby ALPHA = ('a'..'z').to_a.freeze r = Ractor.new do puts ALPHA # The strings aren't frozen, so we get Ractor::IsolationError during access end.join ``` ## The Issue The way implicit shareability is implemented is that the Ractor that's doing the access first checks if the object has a shareable flag. If it does then it can access it, otherwise it traverses the object to check shareability for all references and sets the shareable flag once it determines the object is shareable (so it doesn't need to traverse again during the next lookup). There are a few issues with this approach: 1) Setting the shareable flag sets a bit in a bitmap on the heap page of the other Ractor. This can race with other bits being set by this Ractor if it's running code or doing GC. 2) Traversing the other Ractor's object graph can mutate the objects internally (such as calling `str_make_independent`). If the owning Ractor is using this object, then it can race (and crash). ## Example For an example of a crash showing issue 2: ```ruby # Repro: a non-owner Ractor reading a class ivar runs the full shareability traversal # on the owner's object graph (rb_ivar_lookup -> rb_ractor_shareable_p -> # rb_obj_traverse -> mark_shareable -> rb_str_make_independent). Several readers do it # at once on the same STR_SHARED strings, racing in str_make_independent_expand: # one clears STR_SHARED and installs a new heap.ptr while another, holding the old # pointer, re-tests the flags and frees it. N_STR = (ENV['N_STR'] || 20_000).to_i N_RACT = (ENV['N_RACT'] || 8).to_i ROUNDS = (ENV['ROUNDS'] || 50).to_i BASE = ("abcdefghij" * 200).freeze # long enough that substrings are STR_SHARED ROUNDS.times do |round| k = Class.new do class << self; attr_accessor :v; end end Object.const_set(:"C#{round}", k) k.v = Array.new(N_STR) { |i| BASE[(i % 100)..].freeze }.freeze start = Process.clock_gettime(Process::CLOCK_MONOTONIC) + 0.05 rs = N_RACT.times.map do Ractor.new(k, start) do |kls, t0| nil while Process.clock_gettime(Process::CLOCK_MONOTONIC) < t0 a = kls.v # <- traverses + promotes the owner's graph a.size + a[0].length end end rs.each(&:value) $stderr.print "." if round % 10 == 0 end $stderr.puts "\nsurvived #{ROUNDS} rounds" ``` ## Possible Fixes 1) We can remove implicit shareability for deeply frozen objects. If an object isn't shareable, access from another Ractor raises `Ractor::IsolationError`. Users must call `Ractor.make_shareable` explicitly. This is a backwards incompatible change. 2) We can do the shareability traversal check and set in the owning Ractor's `#freeze`. This would only need to be done for objects that are directly pointed to by shareable objects like classes/modules. This allows the checking Ractor to simply check the shareable flag on the object's flags (FL_SHAREABLE). For example: ```ruby class C @iv = ["iv".freeze].freeze # During ivar set of a class, if the object is frozen, we do the shareability check graph walk end ``` This means that each time a class/module sets an ivar, a cvar or a constant and the object is frozen, we need to walk all references (until we see a non-shareable object). This slows down these operations, but there may not be many of them and most of them are probably on boot. This also increases the number of shareable objects, because previously frozen objects are now set frozen + shareable. This makes no difference in single-ractor mode, but possibly causes more global GCs in multi-ractor mode. 3) The checking Ractor blocks on read of a non-shareable, the owning Ractor performs the check then unblocks the checking Ractor with the result of the object's shareability. There are complications here because of global GC and the asynchronous nature of the message passing. It could also be slow if this continues to happen after boot. However, the "check shareability on read" semantics are preserved and it doesn't have the problem of making more objects shareable than we have to. ## Code I have a [PR](https://github.com/ruby/ruby/pull/19283) that implements solution 2 and @jhawthorn is working on implementing solution 3. ## Feedback Let us know how you think this implicit shareability check should work or if we should even have it to begin with. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126892] [Ruby Bug#22396] Using rb_postponed_job_trigger causes YJIT/ZJIT compiled methods side exits
by ivoanjo (Ivo Anjo) 20 Oct '26

20 Oct '26

Issue #22396 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #22396: Using rb_postponed_job_trigger causes YJIT/ZJIT compiled methods side exits https://bugs.ruby-lang.org/issues/22396 * Author: ivoanjo (Ivo Anjo) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [x86_64-linux] / ruby 4.1.0dev (2026-09-28T09:36:41Z master d939272e7d) +YJIT +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hey 👋. So at Datadog, while working on the [datadog ruby profiler](https://github.com/DataDog/dd-trace-rb/) we've uncovered something that may-or-may-not be a bug, but really surprised us so I wanted to open up a ticket to discuss. Our profiler uses a design where we interrupt Ruby using a SIGPROF signal, collect frames from inside the signal handler (using our homegrown copy of `rb_profile_frames`) and then use `rb_postponed_job_trigger` to get to a safepoint where we can process the data. Unfortunately, we weren't aware of `rb_postponed_job_trigger` causing JIT side exits! For small methods this is hard to measure, but with a reasonably long-running loop, this becomes measurable. I've built (with AI friend) a reproducer for this. Out of curiosity I also added support for stackprof and rperf which also use a similar design (vernier doesn't! :D) to discard it being something else in the Datadog profiler design. Here's how it looks with just interpreter: ``` $ PROFILER=datadog be ruby --disable-yjit --disable-zjit profiling_jit.rb Profiler: datadog ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] Calculating ------------------------------------- Warmup 21.511 (± 4.6%) i/s (46.49 ms/i) - 108.000 in 5.020785s Calculating ------------------------------------- Profiler off 21.974 (± 4.6%) i/s (45.51 ms/i) - 110.000 in 5.005813s Calculating ------------------------------------- Profiler on 20.865 (± 4.8%) i/s (47.93 ms/i) - 105.000 in 5.032376s Calculating ------------------------------------- Profiler off again 21.455 (± 9.3%) i/s (46.61 ms/i) - 108.000 in 5.033813s Comparison: Profiler off: 22.0 i/s Profiler off again: 21.5 i/s - same-ish: difference falls within error Profiler on: 20.9 i/s - same-ish: difference falls within error ``` Here's how it looks with YJIT (ZJIT shows similar results): ``` $ PROFILER=datadog bundle exec ruby --yjit --yjit-call-threshold=1 profiling_jit.rb Profiler: datadog ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [x86_64-linux] Calculating ------------------------------------- Warmup 192.433 (± 5.7%) i/s (5.20 ms/i) - 963.000 in 5.004347s Calculating ------------------------------------- Profiler off 192.959 (± 5.2%) i/s (5.18 ms/i) - 965.000 in 5.001050s Calculating ------------------------------------- Profiler on 50.250 (± Inf%) i/s (19.90 ms/i) - 253.000 in 5.034844s Calculating ------------------------------------- Profiler off again 192.072 (± 6.2%) i/s (5.21 ms/i) - 961.000 in 5.003330s Comparison: Profiler off: 193.0 i/s Profiler off again: 192.1 i/s - same-ish: difference falls within error Profiler on: 50.2 i/s - 3.84x slower ``` ...and here's with YJIT stats to show the side exits count going up: ``` $ PROFILER=datadog bundle exec ruby --yjit --yjit-call-threshold=1 --yjit-stats=quiet profiling_jit.rb Profiler: datadog ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +YJIT +PRISM [x86_64-linux] Calculating ------------------------------------- Warmup 2.246 (± 0.0%) i/s (445.30 ms/i) - 12.000 in 5.343558s Side exits: 2 Calculating ------------------------------------- Profiler off 2.512 (± 0.0%) i/s (398.08 ms/i) - 13.000 in 5.175023s Side exits: 1 Calculating ------------------------------------- Profiler on 19.632 (± 5.1%) i/s (50.94 ms/i) - 99.000 in 5.042706s Side exits: 101 Calculating ------------------------------------- Profiler off again 2.505 (± 0.0%) i/s (399.12 ms/i) - 13.000 in 5.188599s Side exits: 1 Comparison: Profiler on: 19.6 i/s Profiler off: 2.5 i/s - 7.82x slower Profiler off again: 2.5 i/s - 7.84x slower ``` (Funnily enough, because `--yjit-stats=quiet` makes the JITted code slower than interpreter, the fact that the profiler forces the code to go back to the interpreter means the code speeds up since interpreter goes vroom) Thus my question is -- is this "rb_postponed_job_trigger always triggers side exit" behavior something that we'll need to work with (possibly adopting a design closer to vernier), or is this something that could be fixed in YJIT or ZJIT to avoid the footgun? --- Some extra data points: * stackprof + master + yjit: ``` $ PROFILER=stackprof ruby --yjit --yjit-call-threshold=1 profiling_jit.rb Profiler: stackprof ruby 4.1.0dev (2026-09-28T09:36:41Z master d939272e7d) +YJIT +PRISM [x86_64-linux] Calculating ------------------------------------- Warmup 190.831 (± 7.9%) i/s (5.24 ms/i) - 954.000 in 4.999178s Calculating ------------------------------------- Profiler off 192.096 (± 6.2%) i/s (5.21 ms/i) - 961.000 in 5.002707s Calculating ------------------------------------- Profiler on 2.621 (± 0.0%) i/s (381.54 ms/i) - 14.000 in 5.341527s Calculating ------------------------------------- Profiler off again 187.173 (± 8.5%) i/s (5.34 ms/i) - 936.000 in 5.000721s Comparison: Profiler off: 192.1 i/s Profiler off again: 187.2 i/s - same-ish: difference falls within error Profiler on: 2.6 i/s - 73.29x slower ``` * stackprof + master + zjit: ``` $ PROFILER=stackprof ruby --zjit --zjit-call-threshold=2 profiling_jit.rb Profiler: stackprof ruby 4.1.0dev (2026-09-28T09:36:41Z master d939272e7d) +ZJIT +PRISM [x86_64-linux] Calculating ------------------------------------- Warmup 178.615 (±11.2%) i/s (5.60 ms/i) - 893.000 in 4.999570s Calculating ------------------------------------- Profiler off 196.171 (± 3.6%) i/s (5.10 ms/i) - 981.000 in 5.000751s Calculating ------------------------------------- Profiler on 2.584 (± 0.0%) i/s (386.97 ms/i) - 13.000 in 5.030555s Calculating ------------------------------------- Profiler off again 192.681 (± 6.2%) i/s (5.19 ms/i) - 964.000 in 5.003085s Comparison: Profiler off: 196.2 i/s Profiler off again: 192.7 i/s - same-ish: difference falls within error Profiler on: 2.6 i/s - 75.91x slower ``` ---Files-------------------------------- profiling_jit.rb (2.62 KB) -- https://bugs.ruby-lang.org/

3 7

[ruby-core:127126] [Ruby Feature#22446] Speed up several core methods in Array, Range, String, Integer, Float and Time
by sferik (Erik Berlin) 19 Oct '26

19 Oct '26

Issue #22446 has been reported by sferik (Erik Berlin). ---------------------------------------- Feature #22446: Speed up several core methods in Array, Range, String, Integer, Float and Time https://bugs.ruby-lang.org/issues/22446 * Author: sferik (Erik Berlin) * Status: Open ---------------------------------------- I've opened a set of pull requests that speed up commonly used core methods. This issue collects them in one place for discussion. Each PR stands on its own, adds its benchmark in the first commit, and has its own tests. All of the numbers below are from an arm64 Mac with clang. Several of these changes depend on the compiler inlining or vectorizing a loop, so numbers from Linux with gcc, and from Windows with MSVC, would be especially welcome. ## Array * **Array#sort and Enumerable#sort_by on numeric arrays**: https://github.com/ruby/ruby/pull/19306 When every element is a Fixnum, or every element is a Float, and `<=>` hasn't been redefined, the elements are sorted directly with a pattern-defeating quicksort (the one used by Rust and Go) instead of going through `ruby_qsort` with a callback for each comparison. Random Integers sort 4–5x faster at 1,000 to 100,000 elements, and reversed arrays sort about 9x faster. `sort_by` now uses the same code instead of its own introsort and goes up to 2.4x faster. For `sort_by`, elements with equal keys may come out in a different order (the docs already call that order indeterminate). The error message for an invalid key may also name a different key than before. * **Array#include?, #index, #rindex and #count with immediate values**: https://github.com/ruby/ruby/pull/19308 When the argument is a Fixnum, a Float or a static Symbol, elements of the same kind are compared as raw VALUEs, eight at a time, instead of calling `rb_equal` on each one. Arrays of 1,000 or more elements are 10–15x faster. Arrays of other kinds of elements are within 1–2% of master. * **Array#eql? when elements are identical**: https://github.com/ruby/ruby/pull/19360 `eql?` now walks the element buffers the way `==` already does, and calls `rb_eql()` only for elements that aren't the same VALUE. On an array of 1,000 Integers it's 4.8x faster, so it's no longer about 4x slower than `==`. ## Range * **Range#to_a on Integer ranges**: https://github.com/ruby/ruby/pull/19319 For Fixnum ranges where `Range#each` hasn't been redefined, the array is allocated at its final size and filled in a loop instead of going through `Enumerable#to_a`. That's 7.7x faster at 10 elements and 35x faster at 1,000. `[*range]` and `Array(range)` are faster too. Because this path doesn't call `super`, a `to_a` from a module included into Range, or a redefined `Enumerable#to_a`, is no longer reached for these ranges. * **Range#include? on ranges of numeric Strings**: https://github.com/ruby/ruby/pull/13959 This fills in the `TODO` in `rb_str_include_range_p` for ranges whose ends are all digits. The digits are checked directly instead of iterating with `String#upto`, and the result is the same as iterating would give. `('1'..'200000').include?('199999')` drops from 13 ms to 150 ns. ## String and Integer * **String#casecmp and #casecmp? on similar strings**: https://github.com/ruby/ruby/pull/19311 This builds on https://github.com/ruby/ruby/pull/17444. The ASCII fast path now compares 16 bytes at a time and looks at single bytes only inside a chunk that differs. Identical strings, or strings that differ only in the case of one letter, are 4–5x faster at 360 bytes and 7–14x faster at 3.6 KB and up. * **String#to_i and Integer() for Bignum results**: https://github.com/ruby/ruby/pull/19332 `str2big_normal` now multiplies once per `BDIGIT`-sized group of digits instead of once per character, the way `str2big_karatsuba` already builds its initial digits. Also, `rb_int_parse_cstr` stops its first scan once the input is too long to fit in an `unsigned long`. Parsing is 1.5x faster at 20 decimal digits and 6.3x faster at 600. Results that fit in a Fixnum aren't affected. ## Float * **Conversions between Float and String**: https://github.com/ruby/ruby/pull/19309 `Float#to_s` gets its digits from Schubfach (the algorithm behind OpenJDK's `Double.toString`) instead of `ruby_dtoa`. `ruby_strtod` tries Eisel-Lemire (the algorithm behind `fast_float`, which the json extension already vendors) before falling back to the existing code. For a random Float, `to_s` is 7x faster and `String#to_f` is 3.2x faster, and `Marshal.dump` and `Marshal.load` are faster as well. This is the largest of the PRs. It adds new code under the Boost and MIT licenses, credited in `LEGAL`, plus a generated table with its generator in `tool/`. It also fixes `Rational#to_f` and `Integer#fdiv`, which could be off by one unit in the last place for large operands, and a `strtod` bug on 32-bit x86. I'm happy to split those fixes into their own tickets if that makes review or backporting easier. ## Time * **Time#strftime**: https://github.com/ruby/ruby/pull/19341 Numeric fields are written directly instead of through `rb_str_catf`, and the result buffer is sized up front so that typical results stay embedded. Common formats are 2.4–4x faster, including the ones used by Logger's default formatter and by Rails' `to_fs(:db)` and `to_fs(:usec)`. I'd appreciate any feedback, here or on the PRs. That includes whether you'd like any of these split up, merged together, or moved into their own tickets. Thank you so much for reviewing! I hope it's not too late for these performance improvements to make it into Ruby 4.1! -- https://bugs.ruby-lang.org/

3 11

[ruby-core:127157] [Ruby Bug#22452] `rb_equal` returns true for `NaN == NaN`
by byroot (Jean Boussier) 19 Oct '26

19 Oct '26

Issue #22452 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #22452: `rb_equal` returns true for `NaN == NaN` https://bugs.ruby-lang.org/issues/22452 * Author: byroot (Jean Boussier) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- I noticed this while trying to cleanup and simplify `rb_equal`. ```ruby >> Float::NAN == Float::NAN => false >> [Float::NAN].index(Float::NAN) => 0 ``` I would expect it to return `nil`. This bug is present on all Ruby versions, except for 2.1 to 2.4. JRuby seem to have the same behavior, but TruffleRuby correctly returns`nil` The bug seem to have been re-introduced by 6e0e067de31511cebec01d176f628442371db879 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:127175] [Ruby Bug#22456] IO#close hangs forever when another thread is writing to the IO from a trap handler (please backport ba68343d3a to 3.4)
by txapelgorri (Ibon Castilla) 19 Oct '26

19 Oct '26

Issue #22456 has been reported by txapelgorri (Ibon Castilla). ---------------------------------------- Bug #22456: IO#close hangs forever when another thread is writing to the IO from a trap handler (please backport ba68343d3a to 3.4) https://bugs.ruby-lang.org/issues/22456 * Author: txapelgorri (Ibon Castilla) * Status: Open * ruby -v: ruby 3.4.11 (2026-09-23 revision 592f1ffdb3) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Description If a thread is blocked writing to an IO **inside a trap handler**, and another thread closes that IO, `IO#close` never returns. The writer gets `IOError: stream closed in another thread` and moves on. The closing thread stays in `IO#close` forever (status `sleep`). This is already fixed on master by ba68343d3a "Allow wakeup mutex to be used in trap context" (GitHub PR #13684, released in 4.0.0). It has no Redmine ticket, and it was never backported. Both 3.4.11 and 3.3.12 still have the old code: `thread_io_wake_pending_closer` locks `busy->wakeup_mutex` with `rb_mutex_lock`, and `rb_notify_fd_close` creates that mutex without `rb_mutex_allow_trap`. The waiting on close came to 3.3 with the backport of #20723, so the hang is a regression in 3.3 and 3.4. ## Reproduction No gems needed: ```ruby # IO#close hangs forever when the thread writing to that IO is running a trap handler. # Usage: ruby repro.rb [trap|thread] mode = ARGV[0] || "trap" r, w = IO.pipe begin loop { w.write_nonblock("x" * 4096) } # fill the pipe so the next write blocks rescue IO::WaitWritable end closer = nil write = lambda do closer = Thread.new { sleep 0.3; w.close; :closed } # close while the other thread is blocked writing begin w.syswrite("y") puts "write: returned" rescue Exception => e puts "write: #{e.class}: #{e.message}" end end if mode == "trap" Signal.trap("USR1") { write.call } Process.kill("USR1", Process.pid) sleep 0.1 until closer else write.call end result = closer.join(3) puts "#{RUBY_DESCRIPTION}, #{mode}: " + (result ? "IO#close returned" : "IO#close HANGS (#{closer.status}) at #{closer.backtrace&.first}") ``` Output (Debian 13, x86_64): ``` $ ruby repro.rb trap write: IOError: stream closed in another thread ruby 3.3.10 (2025-10-23 revision 343ea05002) [x86_64-linux], trap: IO#close HANGS (sleep) at repro.rb:13:in `close' $ ruby repro.rb thread write: IOError: stream closed in another thread ruby 3.3.10 (2025-10-23 revision 343ea05002) [x86_64-linux], thread: IO#close returned $ ruby repro.rb trap write: IOError: stream closed in another thread ruby 3.4.10 (2026-06-30 revision 2b0b7728dc) +PRISM [x86_64-linux], trap: IO#close HANGS (sleep) at repro.rb:13:in 'IO#close' $ ruby repro.rb thread write: IOError: stream closed in another thread ruby 3.4.10 (2026-06-30 revision 2b0b7728dc) +PRISM [x86_64-linux], thread: IO#close returned ``` Same with the latest releases of each branch (`trap` mode): ``` ruby 3.3.12 (2026-07-16 revision 0581089df9) [x86_64-linux], trap: IO#close HANGS (sleep) at repro.rb:13:in `close' ruby 3.4.11 (2026-09-23 revision 592f1ffdb3) +PRISM [x86_64-linux], trap: IO#close HANGS (sleep) at repro.rb:13:in 'IO#close' ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux], trap: IO#close returned ``` `IO#write` / `<<` behave the same as `syswrite`. ## Why it hangs (3.4) `rb_notify_fd_close` moves the writer's `waiting_fd` to `busy->pending_fd_users`, and `rb_notify_fd_close_wait` sleeps on `busy->wakeup_mutex` until that list is empty. The writer removes itself in `thread_io_wake_pending_closer`, which first calls `rb_mutex_lock(wfd->busy->wakeup_mutex)`. In trap context, `do_mutex_lock` refuses the lock ("can't be called from trap context"), so `rb_mutex_lock` raises before `ccan_list_del()` and `rb_thread_wakeup()`. The entry is never removed, and the closing thread is never woken. Because the `waiting_fd` lives on the writer's C stack, the list is also left pointing at a dead frame. The exception that surfaces is the pending `IOError`, not a `ThreadError`. With a 3.4.10 build instrumented around that call, `do_mutex_lock` takes the trap branch, and `rb_mutex_lock` returns with `TAG_RAISE` and `IOError` in `errinfo`. `TracePoint(:raise)` sees no `ThreadError` at all. ## Real-world impact This is the hang that ba68343d3a was written for: Puma stopping on SIGTERM. In single mode, Puma runs the whole graceful stop inside its SIGTERM trap. `Server#stop` writes to its notification pipe (`notify_safely`) while the server thread closes that pipe in `handle_servers`. The server thread hangs in `IO#close` (puma/server.rb:432), the main thread hangs in `join` (server.rb:668) inside the trap, and systemd ends up sending SIGKILL. We hit it in production with Puma 7.2.1 and Solid Queue running inside Puma, on Ruby 3.3.10. Five of seven stops hung. A thread dump taken during the hang showed exactly those two frames. The puma/puma#3940 change (`syswrite` instead of `<<`) does not avoid it, because the writer is still in a trap. As a workaround, we changed Puma's TERM/INT traps to `Thread.new { stop }`, so that the stop runs outside trap context. With that change, five of five stops were clean. ## Suggested backport (3.4 / 3.3) The fix on master is in `rb_thread_io_close_interrupt`, which does not exist on these branches: master moved to per-IO blocking operations in 425fa0aeb5 (GH-13127) before the fix, so ba68343d3a does not cherry-pick. The equivalent change is in `rb_notify_fd_close` (thread.c). It mirrors what `io.c` already does for `fptr->write_lock`. Patch against 3.4.10 (attached as `allow-trap-3.4.patch`): ```diff if (has_any) { wakeup_mutex = rb_mutex_new(); RBASIC_CLEAR_CLASS(wakeup_mutex); /* hide from ObjectSpace */ + rb_mutex_allow_trap(wakeup_mutex, 1); } ``` Tested on Debian 13, x86_64, with the script above (`trap` mode, 20 runs each): | Ruby | Result | |---|---| | 3.4.10, unpatched | IO#close hangs 20/20 | | 3.4.10 + this patch (built from the release tarball) | IO#close returns 20/20 | | 4.0.7 (already contains ba68343d3a) | IO#close returns 20/20 | `thread` mode returns in all three. With the patch, `make test-all TESTS="ruby/test_io.rb ruby/test_thread.rb ruby/test_signal.rb ruby/test_thread_queue.rb"` passes: 406 tests, 8899 assertions, 0 failures, 0 errors, 1 skip. The same hunk should apply to 3.3, where `rb_notify_fd_close` is identical. Only the line numbers change. I have not built it on 3.3. ---Files-------------------------------- allow-trap-3.4.patch (279 Bytes) repro.rb (853 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:127174] [Ruby Bug#22455] Per-Ractor GC: an idle Ractor costs ~100 KB of memory (17 KB on 4.0)
by matteo.folin＠gmail.com (Matteo Folin) 19 Oct '26

19 Oct '26

Issue #22455 has been reported by matteo.folin(a)gmail.com (Matteo Folin). ---------------------------------------- Bug #22455: Per-Ractor GC: an idle Ractor costs ~100 KB of memory (17 KB on 4.0) https://bugs.ruby-lang.org/issues/22455 * Author: matteo.folin(a)gmail.com (Matteo Folin) * Status: Open * ruby -v: ruby 4.1.0preview1 (2026-10-11 master 2d08b5f42f) +PRISM [aarch64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ### Description With the per-Ractor GC, an idle Ractor (blocked in `Ractor.receive`) costs ~101 KB of RSS against ~17 KB on 4.0.7. In our server, a connection's Ractor, with a few threads and a few hundred live objects, went from ~55–80 KB on 4.0 to ~590 KB on 4.1. 25,000 connections need ~15 GB instead of ~1.4 GB. The per-Ractor GC removes our main 4.0 problem: every GC used to stop and mark all Ractors, so its pauses grew with the number of connections. A Ractor per connection is the shape it should favour. At this memory cost, that shape is hard to use for many connections. Is the floor per Ractor (heap pages per size class?) expected, and can it be lowered, for example by allocating a Ractor's pages lazily or sharing partly-used pages? ### Reproduction ```ruby # 4,000 Ractors blocked in Ractor.receive: memory each, and the cost of a full GC. Warning[:experimental] = false def rss_mb = File.read("/proc/self/status")[/VmRSS:\s+(\d+)/, 1].to_i / 1024.0 def now_ms = Process.clock_gettime(Process::CLOCK_MONOTONIC) * 1000 GC.start base = rss_mb ractors = Array.new(4000) { Ractor.new { Ractor.receive } } sleep 1 puts format("rss per idle Ractor: %.0f KB", (rss_mb - base) * 1024 / ractors.size) 3.times do t = now_ms GC.start puts format("GC.start: %.1f ms", now_ms - t) end ``` ### Results Same machine as above. | | 4.0.7 | 4.1.0-preview1 | |---|---|---| | RSS per idle Ractor | 17 KB | 101 KB | | `GC.start` (global) with 4,000 idle Ractors | 10–21 ms | 43–141 ms | The global GC's cost matters together with Bug #22454: if global GCs are what reclaims exited Ractors, a server that holds thousands of Ractors pays this pause each time. We saw single global GCs of 0.8–3.9 s, most of it sweeping, in a server holding 2,000–5,000 connection Ractors. -- https://bugs.ruby-lang.org/

1 0