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

[ruby-core:123795] [Ruby Bug#21685] Unnecessary context-switching, especially bad on multi-core machines.
by jpl-coconut (Jacob Lacouture) 16 Apr '26

16 Apr '26

Issue #21685 has been reported by jpl-coconut (Jacob Lacouture). ---------------------------------------- Bug #21685: Unnecessary context-switching, especially bad on multi-core machines. https://bugs.ruby-lang.org/issues/21685 * Author: jpl-coconut (Jacob Lacouture) * Status: Open * ruby -v: ruby 3.4.7 (2025-10-08 revision 7a5688e2a2) +PRISM [aarch64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- While debugging a performance issue in a large rails application, I wrote a minimal microbenchmark that reproduces the issue. [[here]](https://gist.github.com/jpl-coconut/cb3679ce885eb578e1071c4b3a525d5c) I was surprised to see that the benchmark takes ~3.6sec on a single-core machine, and ~36sec **(10x slower) on a machine with 2 or more cores** . Initially I thought this was a bug in the implementation of Thread::Queue, but soon realized it relates to how the ruby reschedules threads around system calls. I prepared a fix in [[this branch]](https://github.com/jpl-coconut/ruby/tree/deferred_thread_wait) which is based off ruby 3.4.7. I can apply the fix to a different branch or to master if that's helpful. The fix simply defers suspending the thread until the syscall has been running for some short interval. I chose 100usec initially, but this could easily be made configurable. I pasted raw benchmark results below from a single run (though I did many runs and the results are stable). My CPU is an Apple M4. After the fix: - Single-core performance improves by 55%, from 3.6sec to 2sec. - Adding cores causes performance to be flat (at 2sec), rather than getting 10x slower. - Multi-core context-switch count reduces by 99.995%, from 1.4 million to ~80 - system_time/user_time ratio drops from (1.2 - 1.6) to 0.65 Here are the benchmark results before my change: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1140773 nonvoluntary_ctxt_switches: 9487 real 0m3.619s user 0m1.653s sys 0m1.950s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 1400110 nonvoluntary_ctxt_switches: 3 real 0m36.223s user 0m9.380s sys 0m14.927s ``` And after: ``` # time taskset --cpu-list 1 ./ruby qtest_simple.rb voluntary_ctxt_switches: 88 nonvoluntary_ctxt_switches: 899 real 0m2.031s user 0m1.209s sys 0m0.743s # time taskset --cpu-list 1,2 ./ruby qtest_simple.rb voluntary_ctxt_switches: 75 nonvoluntary_ctxt_switches: 8 real 0m2.062s user 0m1.279s sys 0m0.783s ``` I was concerned these results might still be reflective of a bug in Thread::Queue, so I also came up with a repro that doesn't rely on it. That one is [[here]](https://gist.github.com/jpl-coconut/aa14e59354abf98f808daaf39baa9a72). Results summary: - Single-core performance improves (this time by only 30%) - Multi-core penalty drops from 4x to 0. - No change to context-switching rates. - system_time/user_time ratio drops from (0.5-1) to 0.15 Before fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.336s user 0m0.211s sys 0m0.118s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m1.424s user 0m0.468s sys 0m0.496s ``` After fix: ``` # time taskset --cpu-list 1 ./ruby mbenchmark.rb voluntary_ctxt_switches: 59 real 0m0.241s user 0m0.202s sys 0m0.032s # time taskset --cpu-list 1,2 ./ruby mbenchmark.rb voluntary_ctxt_switches: 60 real 0m0.238s user 0m0.195s sys 0m0.035s ``` -- https://bugs.ruby-lang.org/

7 16

[ruby-core:116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default
by byroot (Jean Boussier) 14 Apr '26

14 Apr '26

Issue #20205 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20205: Enable `frozen_string_literal` by default https://bugs.ruby-lang.org/issues/20205 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context The `frozen_string_literal: true` pragma was introduced in Ruby 2.3, and as far as I'm aware the plan was initially to make it the default for Ruby 3.0, but this plan was abandoned because it would be too much of a breaking change without any real further notice. According to Matz, he still wishes to enable `frozen_string_literal` by default in the future, but a reasonable migration plan is required. The main issue is backward compatibility, flipping the switch immediately would break a lot of code, so there must be some deprecation period. The usual the path forward for this kind of change is to emit deprecation warnings one of multiple versions in advance. One example of that was the Ruby 2.7 keyword argument deprecation. It was quite verbose, and some users were initially annoyed, but I think the community pulled through it and I don't seem to hear much about it anymore. So for frozen string literals, the first step would be to start warning when a string that would be frozen in the future is mutated. ### Deprecation Warning Implementation I implemented a quick proof of concept with @etienne in https://github.com/Shopify/ruby/pull/549 In short: - Files with `# frozen_string_literal: true` or `# frozen_string_literal: false` don't change in behavior at all. - Files with no `# frozen_string_literal` comment are compiled to use `putchilledstring` opcode instead of regular `putstring`. - This opcode mark the string with a user flag, when these strings are mutated, a warning is issued. Currently the proof of concept issue the warning at the mutation location, which in some case can make locating where the string was allocated a bit hard. But it is possible to improve it so the message also include the location at which the literal string was allocated, and learning from the keyword argument warning experience, we can record which warnings were already issued to avoid spamming users with duplicated warnings. As currently implemented, there is almost no overhead. If we modify the implementation to record the literal location, we'd incur a small memory overhead for each literal string in a file without an explicit `frozen_string_literal` pragma. But I believe we could do it in a way that has no overhead if `Warning[:deprecated] = false`. ### Timeline The migration would happen in 3 steps, each step can potentially last multiple releases. e.g. `R0` could be `3.4`, `R1` be `3.7` and `R2` be `4.0`. I don't have a strong opinion on the pace. - Release `R0`: introduce the deprecation warning (only if deprecation warnings enabled). - Release `R1`: make the deprecation warning show up regardless of verbosity level. - Release `R2`: make string literals frozen by default. ### Impact Given that `rubocop` is quite popular in the community and it has enforced the usage of `# frozen_string_literal: true` for years now, I suspect a large part of the actively maintained codebases in the wild wouldn't see any warnings. And with recent versions of `minitest` enabling deprecation warnings by default (and [potentially RSpec too](https://github.com/rspec/rspec-core/issues/2867)) the few that didn't migrate will likely be made compatible quickly. The real problem of course are the less actively developed libraries and applications. For such cases, any codebase can remain compatible by setting `RUBYOPT="--disable=frozen_string_literal"`, and so even after `R2` release. The flag would never be removed any legacy codebase can continue upgrading Ruby without changing a single line of cod by just flipping this flag. ### Workflow for library maintainers As a library maintainer, fixing the deprecation warnings can be as simple as prepending `# frozen_string_literal: false` at the top of all their source files, and this will keep working forever. Alternatively they can of course make their code compatible with frozen string literals. Code that is frozen string literal compatible doesn't need to explicitly declare it. Only code that need it turned of need to do so. ### Workflow for application owners For application owners, the workflow is the same than for libraries. However if they depend on a gem that hasn't updated, or that they can't upgrade it, they can run their application with `RUBYOPT="--disable=frozen_string_literal"` and it will keep working forever. Any user running into an incompatibility issue can set `RUBYOPT="--disable=frozen_string_literal"` forever, even in `4.x`, the only thing changing is the default value. And any application for which all dependencies have been made fully frozen string literal compatible can set `RUBYOPT="--enable=frozen_string_literal"` and start immediately removing magic comment from their codebase. -- https://bugs.ruby-lang.org/

23 82

[ruby-core:125143] [Ruby Misc#21968] The pathname gem needs a new release
by Eregon (Benoit Daloze) 14 Apr '26

14 Apr '26

Issue #21968 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21968: The pathname gem needs a new release https://bugs.ruby-lang.org/issues/21968 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- The current pathname gem release (0.4.0) has several issues: ### Many warnings on Ruby 4.0 It emits many constant & method redefinition warnings. This happens notably when an application has `pathname` as a dependency (direct or transitive) in the Gemfile. This is with the default `$VERBOSE`: ``` $ gem i pathname $ ruby -e 'gem "pathname"; require "pathname"' /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:17: warning: already initialized constant Pathname::VERSION <internal:pathname_builtin>:194: warning: previous definition of VERSION was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:36: warning: already initialized constant Pathname::SEPARATOR_LIST <internal:pathname_builtin>:312: warning: previous definition of SEPARATOR_LIST was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:37: warning: already initialized constant Pathname::SEPARATOR_PAT <internal:pathname_builtin>:313: warning: previous definition of SEPARATOR_PAT was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:43: warning: already initialized constant Pathname::ABSOLUTE_PATH <internal:pathname_builtin>:323: warning: previous definition of ABSOLUTE_PATH was here ``` And 53 warnings with `-w`: ``` $ ruby -we 'gem "pathname"; require "pathname"' /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:17: warning: already initialized constant Pathname::VERSION <internal:pathname_builtin>:194: warning: previous definition of VERSION was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:36: warning: already initialized constant Pathname::SEPARATOR_LIST <internal:pathname_builtin>:312: warning: previous definition of SEPARATOR_LIST was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:37: warning: already initialized constant Pathname::SEPARATOR_PAT <internal:pathname_builtin>:313: warning: previous definition of SEPARATOR_PAT was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:43: warning: already initialized constant Pathname::ABSOLUTE_PATH <internal:pathname_builtin>:323: warning: previous definition of ABSOLUTE_PATH was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:50: warning: method redefined; discarding old chop_basename <internal:pathname_builtin>:359: warning: previous definition of chop_basename was here /home/eregon/.rubies/ruby-4.0.1/lib/ruby/gems/4.0.0/gems/pathname-0.4.0/lib/pathname.rb:61: warning: method redefined; discarding old split_names <internal:pathname_builtin>:370: warning: previous definition of split_names was here ... ``` See https://github.com/ruby/pathname/issues/66 ### The gem fails to install on JRuby See https://github.com/ruby/pathname/issues/94#issuecomment-4016566593 ### The gem crashes on TruffleRuby It causes errors like `pathname.so: undefined symbol: rb_block_call_kw`. See https://github.com/ruby/pathname/issues/94#issue-4038536603 ### Release request These 3 issues are fixed on ruby/pathname master by https://github.com/ruby/pathname/pull/56 and https://github.com/ruby/pathname/pull/57, but no release including those fixes has been published yet. I also opened a GitHub issue about the release request here: https://github.com/ruby/pathname/issues/94. Would it be possible to make a new pathname release? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:125164] [Ruby Feature#21975] Add "UTF-八" as an alias for UTF-8 encoding
by ko1 (Koichi Sasada) 13 Apr '26

13 Apr '26

Issue #21975 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #21975: Add "UTF-八" as an alias for UTF-8 encoding https://bugs.ruby-lang.org/issues/21975 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- In Japan, legal texts must write all characters - including digits - using full-width or kanji forms. As a result, the encoding name "UTF-8" appears as "UTF-八" (八 = eight in kanji) in official government notices. Specifically, it appears in a notice issued by the Digital Agency and the Ministry of Internal Affairs and Communications (令和8年デジタル庁・総務省告示第12号), which defines character sets and encoding for local government information systems: > 地方公共団体情報システムの標準化に関する法律第七条第一項に規定する各地方公共団体情報システムに共通する基準のうち電磁的記録において用いられる用語及び符号の相互運用性の確保その他の地方公共団体情報システムに係る互換性の確保に関する標準を定める命令第三条第二号の規定に基づき行政事務標準文字の文字セット及び地方公共団体情報システム間の連携のための文字符号化方式を定める告示 Reference: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resourc… This patch <https://github.com/ruby/ruby/pull/16623> adds "UTF-八" as an encoding alias for UTF-8, so that Ruby is compliant with Japanese law. ```ruby # encoding: UTF-八 p __ENCODING__ #=> #<Encoding:UTF-8> p Encoding.find("UTF-八") #=> #<Encoding:UTF-8> p "hello".encode("UTF-八") #=> "hello" p "こんにちは".force_encoding("UTF-八") #=> "こんにちは" p "こんにちは".encode("ＵＴＦ｜八") #=> "こんにちは" ``` -- https://bugs.ruby-lang.org/

5 5

[ruby-core:123836] [Ruby Feature#21695] Optimizing Ruby performance with Ruby itself instead of Rust
by fredlinhares (Frederico Linhares) 10 Apr '26

10 Apr '26

Issue #21695 has been reported by fredlinhares (Frederico Linhares). ---------------------------------------- Feature #21695: Optimizing Ruby performance with Ruby itself instead of Rust https://bugs.ruby-lang.org/issues/21695 * Author: fredlinhares (Frederico Linhares) * Status: Open ---------------------------------------- I am using ERB on top of C for a game I am making now. We can use the tool to improve the productivity, memory safety, and runtime speed for Ruby. It can also replace a Rust JIT compiler for better results. The only problem is that it requires some level of manual memory management, while Rust does it all for you. If I demonstrate that it is better than Rust in practice, would you be willing to incorporate it into the Ruby language? I want to know because making it more generic will require more effort from me; if you are not interested, I won’t make the tool public. -- https://bugs.ruby-lang.org/

6 10

[ruby-core:124711] [Ruby Feature#21869] Add receive_all Method to Ractor API for Message Batching
by synacker (Mikhail Milovidov) 05 Apr '26

05 Apr '26

Issue #21869 has been reported by synacker (Mikhail Milovidov). ---------------------------------------- Feature #21869: Add receive_all Method to Ractor API for Message Batching https://bugs.ruby-lang.org/issues/21869 * Author: synacker (Mikhail Milovidov) * Status: Open ---------------------------------------- **Summary** The Ractor API provides an excellent mechanism for inter‑thread communication, but it currently lacks a built‑in message batching technique. I propose adding a receive_all method to enable batch processing of messages, which can significantly improve performance in high‑load scenarios. **Motivation** In distributed queued systems, processing messages one‑by‑one (as with the current receive method) can introduce unnecessary overhead. Batch processing allows: Reduced context‑switching overhead. More efficient I/O operations (e.g., fewer file writes). Better throughput in high‑concurrency environments. **Proposed Solution** Add a receive_all method to the Ractor API that: Returns all available messages in the Ractor’s mailbox at once (as an array). **Demonstration Code** Below is a benchmark comparing individual receive vs. batch receive_all: ``` ruby require 'benchmark' class RactorsTest def initialize(count) @count = count @ractor1 = Ractor.new(count, 'output1.txt') do |count, filename| File.open(filename, 'w') do |file| while count.positive? message = receive file.write("Ractor 1 received message: #{message}\n") file.flush count -= 1 end end end @ractor2 = Ractor.new(count, 'output2.txt') do |count, filename| File.open(filename, 'w') do |file| while count.positive? messages = receive_all messages.each do |message| file.write("Ractor 2 received message: #{message}\n") end count -= messages.length file.flush end end end end def run1 @count.times do |i| @ractor1.send("Message #{i + 1}") end @ractor1.join end def run2 @count.times do |i| @ractor2.send("Message #{i + 1}") end @ractor2.join end end records = 1_000_000 test = RactorsTest.new(records) p [:once, Benchmark.realtime { test.run1 }.round(2)] p [:all, Benchmark.realtime { test.run2 }.round(2)] ``` **Benchmark Results** On my system, receive_all shows ~4x improvement over individual receive: **Key Observations:** Ractor1 (using receive): Processes each message individually, resulting in frequent I/O calls. Ractor2 (using receive_all): Processes all queued messages at once, minimizing I/O overhead -- https://bugs.ruby-lang.org/

4 10

[ruby-core:123883] [Ruby Feature#21704] Expose rb_process_status_new to C extensions
by noteflakes (Sharon Rosner) 04 Apr '26

04 Apr '26

Issue #21704 has been reported by noteflakes (Sharon Rosner). ---------------------------------------- Feature #21704: Expose rb_process_status_new to C extensions https://bugs.ruby-lang.org/issues/21704 * Author: noteflakes (Sharon Rosner) * Status: Open ---------------------------------------- A fiber scheduler implementation with a hook for `#process_wait` needs to return a `Process::Status` object, but currently it is not possible for a C extension to directly create an instance of `Process::Status`. The technique currently used in various fiber scheduler implementations is to use `pidfd_open`, poll for fd readiness, then call `Process::Status.wait`, which creates the instance. On recent Linux kernels (6.7 or newer), `io_uring_prep_waitid` can be used to directly wait for process termination, which provides us with the pid and status of the terminated child process, but there's no way to directly create an instance of `Process::Status`, required for implementing the `#process_wait` hook. Exposing the internal `rb_process_status_new` function would allow such an implementation. Using `io_uring_prep_waitid` would also lead to better compatibility of fiber schedulers with calls to `Process.wait(0)` or `Process.wait(-1)`, as those cannot be done using `pidfd_open`. The associated PR is here: https://github.com/ruby/ruby/pull/15213 An working fiber scheduler implementation of `process_wait` using `io_uring_prep_waitid` has been submitted here: https://github.com/socketry/io-event/pull/154 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:124270] [Ruby Bug#21787] `IO::Buffer` buffer overf
by nobu (Nobuyoshi Nakada) 03 Apr '26

03 Apr '26

Issue #21787 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #21787: `IO::Buffer` buffer overf https://bugs.ruby-lang.org/issues/21787 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125028] [Ruby Bug#21954] NoMethodError instead of Gem::LoadError on gem activation problem in Ruby 4.0.2
by jeremyevans0 (Jeremy Evans) 03 Apr '26

03 Apr '26

Issue #21954 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Bug #21954: NoMethodError instead of Gem::LoadError on gem activation problem in Ruby 4.0.2 https://bugs.ruby-lang.org/issues/21954 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [x86_64-linux] * Backport: 3.2: DONTNEED, 3.3: DONTNEED, 3.4: DONTNEED, 4.0: REQUIRED ---------------------------------------- I'm seeing a regression in Ruby 4.0.2 when there is a gem activation problem. Install two versions of a gem, where one version has a file the other doesn't. One example here is rack: ``` $ gem install rack --version '< 3' $ gem install rack ``` Force activation of the version that doesn't have the file, and then require the file and rescue `LoadError`: ```ruby gem 'rack', '< 3' begin require 'rack/headers' rescue LoadError end ``` In previous versions of Ruby, the `Gem::LoadError` would be correctly rescued, and you would get no output. In Ruby 4.0.2, you get a `NoMethodError` raised: ``` /usr/local/lib/ruby/4.0/rubygems.rb:196:in 'Gem.try_activate': undefined method 'name' for nil (NoMethodError) spec ||= Gem::Specification.find_by_name(spec.name) ^^^^^ from /home/jeremy/gem-activate-problem.rb:4:in 'Kernel#require' from /home/jeremy/gem-activate-problem.rb:4:in '<main>' /usr/local/lib/ruby/4.0/rubygems/specification.rb:2170:in 'Gem::Specification#check_version_conflict': can't activate rack-3.2.4, already activated rack-2.2.21 (Gem::LoadError) from /usr/local/lib/ruby/4.0/rubygems/specification.rb:1379:in 'Gem::Specification#activate' from /usr/local/lib/ruby/4.0/rubygems.rb:193:in 'Gem.try_activate' from /home/jeremy/gem-activate-problem.rb:4:in 'Kernel#require' from /home/jeremy/gem-activate-problem.rb:4:in '<main>' /home/jeremy/gem-activate-problem.rb:4:in 'Kernel#require': cannot load such file -- rack/headers (LoadError) from /home/jeremy/gem-activate-problem.rb:4:in '<main>' ``` Same behavior on both OpenBSD and Linux. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:125154] [Ruby Bug#21971] Backport commit 5de4cc560864 / PR #15848
by mackuba (Kuba Suder) 03 Apr '26

03 Apr '26

Issue #21971 has been reported by mackuba (Kuba Suder). ---------------------------------------- Bug #21971: Backport commit 5de4cc560864 / PR #15848 https://bugs.ruby-lang.org/issues/21971 * Author: mackuba (Kuba Suder) * Status: Open * ruby -v: ruby 4.0.2 (2026-03-17 revision d3da9fec82) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Follow-up to ticket: https://bugs.ruby-lang.org/issues/21824 There was a group of old commits merged before 4.0 which were meant to improve regexp performance in some cases. Unfortunately, they also greatly degraded regexp performance in some other cases. This was released in version 4.0.0, where I noticed it when testing the performance of the final version in my app, and reported it as 21824. Chris Hasiński has fixed this on the master branch in commit 5de4cc56086493689701e86aa0ccf6a4a4a87d75, however this wasn't released as a bugfix with Ruby 4.0.1 & 4.0.2. It would be great if this could be backported to the ruby_4_0 branch and included in the 4.0.3 bugfix release. -- https://bugs.ruby-lang.org/

3 3