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

[ruby-core:124278] [Ruby Feature#21788] Promote Thread::Monitor to a core class
by byroot (Jean Boussier) 10 Feb '26

10 Feb '26

Issue #21788 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21788: Promote Thread::Monitor to a core class https://bugs.ruby-lang.org/issues/21788 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- `Monitor` is about as useful as `Mutex` and yet one is a core class and the other is a "stdlib" extension. I propose to promote `Thread::Monitor` as a core class convenience. ### The rest of `monitor.rb` The `monitor` stdlib also contains `MonitorMixin`, but I think this part can remain in `lib/monitor.rb` (or even be moved to `lib/monitor_mixin.rb`. One more questionable part is `Monitor#new_cond`, as it returns a `::MonitorMixin::ConditionVariable` so it would also need to remain in the stdlib. ### Performance benefit By being a core class, Monitor can also be implemented more efficiently, as it is no longer constrained to the public C API. On my branch, monitor is approximately 15% faster (but there might be some more optimizations to be found). `master`: ``` ruby 4.0.0dev (2025-12-17T07:21:34Z core-monitor 32815a1bc4) +YJIT +PRISM [arm64-darwin25] Warming up -------------------------------------- Mutex 1.975M i/100ms Monitor 1.936M i/100ms Calculating ------------------------------------- Mutex 25.213M (± 0.4%) i/s (39.66 ns/i) - 126.407M in 5.013728s Monitor 24.099M (± 0.1%) i/s (41.50 ns/i) - 121.992M in 5.062092s ``` core monitor: ``` ruby 4.0.0dev (2025-12-17T07:16:32Z master 54d3945ee5) +YJIT +PRISM [arm64-darwin25] Warming up -------------------------------------- Mutex 1.952M i/100ms Monitor 1.775M i/100ms Calculating ------------------------------------- Mutex 25.102M (± 0.4%) i/s (39.84 ns/i) - 126.884M in 5.054731s Monitor 21.189M (± 0.1%) i/s (47.19 ns/i) - 106.485M in 5.025493s ``` Proposed implementation: https://github.com/ruby/ruby/pull/15538 -- https://bugs.ruby-lang.org/

4 8

[ruby-core:124552] [Ruby Bug#21838] Rails seeding degradation (20% slowdown) related to Revision 079ef92b "Implement global allocatable slots and empty pages" (from Sep 5 2024)
by bluz71 (Dennis B) 09 Feb '26

09 Feb '26

Issue #21838 has been reported by bluz71 (Dennis B). ---------------------------------------- Bug #21838: Rails seeding degradation (20% slowdown) related to Revision 079ef92b "Implement global allocatable slots and empty pages" (from Sep 5 2024) https://bugs.ruby-lang.org/issues/21838 * Author: bluz71 (Dennis B) * Status: Open * ruby -v: ruby 3.4.0dev (2024-09-09T14:15:21Z v3_4_0_preview2~545 079ef92b5e) * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I noticed a performance degradation with Ruby 3.4 when seeding my Rails application, which does image derivation via the Shrine Gem and `libvips` image library. I skipped Ruby 3.4 hoping that 4.0 would magically solve my performance issue. Alas not. My degradation when doing `rails db:reset` (aka database seeding) was about 20% as compared with Ruby 3.3. The last couple of days I looked at this issue more closely and with the help of `git bisect` I believe this commit: https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/07… is the cause of my regression. That commit implements global allocatable slots and empty pages. The revision before is fast when seeding my Rails application. This revision however slows down my Rails seeding by about 20%, from 30 seconds to 40 seconds consistently. I created a minimal Rails application as the reproducible test case: https://github.com/bluz71/rails_app_ruby_slowdown Steps to reproduce: 1. `git clone https://github.com/bluz71/rails_app_ruby_slowdown` 2. `cd rails_app_ruby_slowdown` 3. `bundle config set force_ruby_platform true` 4. `bundle install` 5. `bundle exec rails db:create` 6. `RUBY_YJIT_ENABLE=0 time bundle exec rails db:reset` Note, `libvips` needs to be installed at the system level, for example `sudo apt install libvips`, libvips is the image processing library used by Shrine which in turn is used in this Rails application when seeding. Use Ruby 3.3 and 3.4 to compare, or use Revision de7ac11a (https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/de…) and Revision 079ef92b (https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/07…) to compare. I hope this is reproducible, if so, I also hope this performance loss can be minimised in future. Best regards. -- https://bugs.ruby-lang.org/

5 6

[ruby-core:124746] [ruby-core:124711][Ruby Feature#/21869] Add receive_all Method to Ractor API for Message Batching
by milovidovmikhail＠gmail.com 09 Feb '26

09 Feb '26

**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 **PR on Github** https://github.com/ruby/ruby/pull/16105

1 0

[ruby-core:123966] [Ruby Bug#21723] `binding.irb` raises a LoadError under `bundle exec`
by osyoyu (Daisuke Aritomo) 09 Feb '26

09 Feb '26

Issue #21723 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Bug #21723: `binding.irb` raises a LoadError under `bundle exec` https://bugs.ruby-lang.org/issues/21723 * Author: osyoyu (Daisuke Aritomo) * Status: Open * ruby -v: ruby 4.0.0preview2 (2025-11-17 master 4fa6e9938c) +PRISM [arm64-darwin24] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- In Ruby 4.0, `binding.irb` raises a LoadError when some unknown condition is met. ```ruby # main.rb binding.irb ``` ``` main.rb:1: warning: irb used to be loaded from the standard library, but is not part of the default gems since Ruby 4.0.0. You can add irb to your Gemfile or gemspec to fix this error. Failed to activate irb, please install it with 'gem install irb' /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'Kernel.require': cannot load such file -- irb (LoadError) Did you mean? erb from /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'block (2 levels) in Kernel#replace_require' from main.rb:1:in 'Binding#irb' from main.rb:1:in '<main>' /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'Kernel.require': cannot load such file -- irb (LoadError) Did you mean? erb from /Users/osyoyu/.rbenv/versions/master/lib/ruby/4.0.0+0/bundled_gems.rb:60:in 'block (2 levels) in Kernel#replace_require' from main.rb:1:in 'Binding#irb' from main.rb:1:in '<main>' ``` While irb has been changed to a bundle gem in #20309, it is agreed that `binding.irb` shall work under `bundle exec` without adding `irb` in Gemfile. Thus, I've considered this behavior as an bug and created a ticket here. One condition I have discovered is when the Gemfile contains a `gem` reference with a `path:` option. I have created a repro repository in https://github.com/osyoyu/irbfail for that case. -- https://bugs.ruby-lang.org/

3 6

[ruby-core:124738] [Ruby Feature#6478] BasicObject#__class__
by Eregon (Benoit Daloze) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by Eregon (Benoit Daloze). byroot (Jean Boussier) wrote in #note-18: > I mean, it's consistent with `__send__` and `__id__`, aliases of `send` and `object_id` meant to be used by generic code that want to ensure it can deal with any object, even ones that would redefine common methods. Yeah, I dislike those too 😅 Specifically I think it looks very unidiomatic (and ugly) when used in Ruby code. I think at least it's clear it's not good to go towards having every `Kernel` method as a `__x__` variant on BasicObject. Also even `__send__` and `__id__` can be redefined, so the `KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj)` approach is in fact safer. So my take on this is `KERNEL_CLASS = Kernel.instance_method(:class); KERNEL_CLASS.bind_call(obj)` is good enough, and also most BasicObject subclasses should implement Kernel-like methods. Concrete examples from real code where this is not good enough would most likely be helpful to move this forward if people want that. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116339 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124735] [Ruby Feature#6478] BasicObject#__class__
by byroot (Jean Boussier) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by byroot (Jean Boussier). Not that I'm for nor against this feature request, but: > In terms of naming I think __class__ looks like a hack that Python would use and not Ruby-like. I mean, it's consistent with `__send__` and `__id__`, aliases of `send` and `object_id` meant to be used by generic code that want to ensure it can deal with any object, even ones that would redefine common methods. > Why not add BasicObject#class? I suspect that would break various proxy classes in gems. Might not be a huge deal. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116336 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124734] [Ruby Feature#6478] BasicObject#__class__
by Eregon (Benoit Daloze) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by Eregon (Benoit Daloze). In terms of naming I think `__class__` looks like a hack that Python would use and not Ruby-like. Why not add `BasicObject#class`? I think `Kernel.instance_method(:class).bind_call(o)` is fine for most cases. FWIW performance-wise on TruffleRuby there isn't much difference when storing the `UnboundMethod` in a constant: ``` truffleruby 33.0.1 (2026-01-20), like ruby 3.3.7, Oracle GraalVM Native [x86_64-linux] Calculating ------------------------------------- instance_method.bind_call 33.492M (± 3.0%) i/s (29.86 ns/i) - 169.962M in 5.079892s bind_call 631.582B (± 1.1%) i/s (0.00 ns/i) - 3.157T in 4.998908s __class__ 750.398B (± 1.3%) i/s (0.00 ns/i) - 3.751T in 4.999106s ``` BasicObject are very difficult to use because they miss so many "standard" methods from Kernel. As such I see them as mostly meant to proxy all the Kernel methods to maybe some delegate object or so, and the responsability of the BasicObject subclass to implement Kernel-like methods to make the object usable in normal Ruby code. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116335 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121683] [Ruby Bug#21272] Class.new doesn't trigger :class TracePoint
by st0012 (Stan Lo) 09 Feb '26

09 Feb '26

Issue #21272 has been reported by st0012 (Stan Lo). ---------------------------------------- Bug #21272: Class.new doesn't trigger :class TracePoint https://bugs.ruby-lang.org/issues/21272 * Author: st0012 (Stan Lo) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- According to the official [documentation](https://docs.ruby-lang.org/en/master/TracePoint.html#class-T…: > To filter what is traced, you can pass any of the following as events: > > :class > Start a class or module definition. I'd expect `:class` events to be triggered when new classes are defined via `Class.new` as well, but currently that's not the case. Should we either support `Class.new`, or clarify the behaviour in documentation? ### Reproduction ```rb TracePoint.trace(:class) do |tp| puts "Class created at line: #{tp.lineno}" end class Foo; end # Triggers the tracepoint Baz = Class.new # Doesn't trigger the tracepoint # ruby test.rb # Class created at line: 5 ``` -- https://bugs.ruby-lang.org/

3 8

[ruby-core:124723] [Ruby Feature#6478] BasicObject#__class__
by jneen (Jeanine Adkisson) 09 Feb '26

09 Feb '26

Issue #6478 has been updated by jneen (Jeanine Adkisson). I wonder if exposing a static `Object.class_of(thing)` would be appropriate? There's also the singleton_class to consider as well. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116321 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124721] [Ruby Feature#6478] BasicObject#__class__
by trinistr (Alexander Bulancov) 08 Feb '26

08 Feb '26

Issue #6478 has been updated by trinistr (Alexander Bulancov). I would like to revive discussion for this feature request as I feel that `BasicObject#__class_` is still needed. Note: obviously, it is possible to transplant methods with `define_method` (that is very nice!), but one doesn't always control the class of the object. **What for?** - Inspection of objects. Currently, it's not possible to print anything reasonable for a BasicObject-derived object. - Introspection. Everything in Ruby is an object with a class, and not being able to get that class is weird and painful. It's possible to use `Kernel.instance_method(:class).bind_call(o)`, but why is this even required? It's very un-ergonomical. **Why?** 1. Printing of classes is especially useful for error messages, and Ruby's internals can just do that (though maybe this is also just `Kernel#class`?): ```ruby class A < BasicObject; end 1.clone(freeze: A.new) # in 'Numeric#clone': unexpected value for freeze: A (ArgumentError) ``` Creating such messages in regular code is unnecessarily hard when any object can happen, it requires conditionals and/or using the `bind_call` trick. 2. Getting a class of an object is probably mostly useful for interactive use (which is still important), but the long incantation to do it is inconvenient and hard to remember as something that can be done. 3. `bind_call` is an order of magnitude slower than just using the method: ```ruby class B < BasicObject; define_method(:__class__, ::Kernel.instance_method(:class)); end b = B.new class_method = Kernel.instance_method(:class) Benchmark.ips { |x| x.report("instance_method.bind_call") { Kernel.instance_method(:class).bind_call(b) } x.report("bind_call") { class_method.bind_call(b) } x.report("__class__") { b.__class__ } } ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [x86_64-linux] Warming up -------------------------------------- instance_method.bind_call 107.359k i/100ms bind_call 119.100k i/100ms __class__ 2.187M i/100ms Calculating ------------------------------------- instance_method.bind_call 1.022M (± 3.3%) i/s (978.28 ns/i) - 5.153M in 5.046952s bind_call 1.147M (± 4.6%) i/s (871.47 ns/i) - 5.836M in 5.096893s __class__ 22.494M (± 3.6%) i/s (44.46 ns/i) - 113.699M in 5.062084s ``` **Compatibility** I believe virtually no code would be negatively impacted by addition of `BasicObject#__class__`. Code would need to both check for the presence of `#__class__` and do something completely divorced from `#class` to be affected. On the other hand, it would allow for a method that doesn't conflict with a keyword. Searching for uses of `__class__` on GitHub (https://github.com/search?q=__class__+language%3Aruby&ref=searchresults&typ…) seems to show just a few current uses: - defining `__class__` to refer to the class of a proxy object itself - `alias __class__ class`, seemingly to call directly instead of `self.class` - Rubinius has it (https://github.com/rubinius/rubinius/blob/84368419a49767ef9549a5778812e5f54…) - Pythonification There are some results that define `__class__` if it doesn't exist already, but those should not be impacted, as the meaning would be the same. **In short** Adding `BasicObject#__class__` would - make it possible to always get the class for any object in the same way; - be faster than current solution; - have no negative impact on existing codebase. ---------------------------------------- Feature #6478: BasicObject#__class__ https://bugs.ruby-lang.org/issues/6478#change-116318 * Author: trans (Thomas Sawyer) * Status: Feedback * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- How else is one supposed to get the class of a subclass of BasicObject? -- https://bugs.ruby-lang.org/

1 0