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

[ruby-core:125140] [Ruby Feature#21966] Remove rb_obj_class runtime check on rb_define_alloc_func returned objects
by jhawthorn (John Hawthorn) 26 Mar '26

26 Mar '26

Issue #21966 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #21966: Remove rb_obj_class runtime check on rb_define_alloc_func returned objects https://bugs.ruby-lang.org/issues/21966 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- I want to remove the following runtime check in `class_call_alloc_func`, replacing it with a `RUBY_ASSERT` (so we would still have the check, but only on a debug build). ``` if (rb_obj_class(obj) != rb_class_real(klass)) { rb_raise(rb_eTypeError, "wrong instance allocation"); } ``` This checks that the value returned from the function registered with `rb_define_alloc_func` is of the correct class. When this was first introduced in 1fe40b7cc5 (by Matz on 2001-10-03), allocation was done via user-defined `Object#allocate`, so it made sense to have a runtime check in release builds. Now that it's defined via `rb_define_alloc_func` in the C extension API, I don't think it's necessary. The check is surprisingly expensive. Removing it makes `Object.new` [about 10% faster](https://gist.github.com/jhawthorn/318ca96f471574080e4f08b6dce759f2). It allows the C compiler to optimize the call to the function pointer as a tail-call. Removing this also allows ZJIT/YJIT to call the function directly (ZJIT already does this by having a list of known safe allocation functions). The diff in the assembly from skipping this is substantial https://gist.github.com/jhawthorn/20834b654bec4ba0bafee729592d5156 (though much of that is `rb_class_real` which I also have plans to improve). There's no way for users to ever have seen this check, other than by writing a misbehaving C extension, which returns objects with the wrong class. https://github.com/ruby/ruby/pull/16571 I don't think this should be controversial, but I'm filing a feature to make sure it has visibility. If anyone has concerns I'll revert the change and discuss here. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124635] [Ruby Feature#21853] Make Embedded TypedData a public API
by byroot (Jean Boussier) 26 Mar '26

26 Mar '26

Issue #21853 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21853: Make Embedded TypedData a public API https://bugs.ruby-lang.org/issues/21853 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- As part of Ruby 3.3, we added a private `RUBY_TYPED_EMBEDDABLE` flag to the `TypedData` API to allow `TypedData` to use variable width allocation. Technically, we inadvertently exposed that flag in public headers so third party extensions can make use of it, but it's not considered public API as it's not documented, so it would be a poor decision. This API has both memory and speed benefits as it allow to avoid some `malloc/free` churn, reduce pointer chasing, etc. For instance, when we converted `Time` to be embedded, it improved allocation performance by 30% and also reduced memory usage by 20%: https://github.com/ruby/ruby/commit/aa6642de630cfc10063154d84e45a7bff30e9103 I believe numerous third party native extensions could benefit from it (I would certainly make use of it in `ruby/json`), now that we used it internally for several years, I'd like to work on making it a public API for Ruby 4.1 -- https://bugs.ruby-lang.org/

3 9

[ruby-core:125072] [Ruby Bug#21958] Snapshot CI is breaking now
by hsbt (Hiroshi SHIBATA) 26 Mar '26

26 Mar '26

Issue #21958 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #21958: Snapshot CI is breaking now https://bugs.ruby-lang.org/issues/21958 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The current snapshot CI used for releases is broken since 14th March. https://github.com/ruby/actions/actions/runs/23065551523/job/67003439358 ``` compiling dump_ast making array.rbinc make[1]: Entering directory '/home/runner/work/actions/actions/snapshot-master' fatal: not a git repository (or any of the parent directories): .git make[1]: 'dump_ast' is up to date. make[1]: Leaving directory '/home/runner/work/actions/actions/snapshot-master' executable host ruby is required. use --with-baseruby option. Note that BASERUBY must be Ruby 3.1.0 or later. make: *** [uncommon.mk:1299: array.rbinc] Error 1 make: *** Waiting for unfinished jobs.... ``` and that Windows build is also failure with another issue: https://github.com/ruby/actions/actions/runs/23261354707/job/67631251910 ``` compiling eventids1.c eventids1.c compiling ../../../snapshot-master/ext/ripper/eventids2.c eventids2.c NMAKE : fatal error U1073: don't know how to make '../../probes.h' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64\nmake.EXE"' : return code '0x2' Stop. ``` I also here the current build system is broken with out-of-source and cross-compile. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:125124] [Ruby Bug#21964] Fiber stack acquire can expand unnecessarily.
by ioquatix (Samuel Williams) 25 Mar '26

25 Mar '26

Issue #21964 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #21964: Fiber stack acquire can expand unnecessarily. https://bugs.ruby-lang.org/issues/21964 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.2: REQUIRED, 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- In several common scenarios, the fiber stack allocator can choose to expand the fiber stack pool even when there are unreachable (effectively dead) fibers. For example, the following program will eventually crash if GC does not run in time: ```ruby loop do Fiber.new{Fiber.yield}.resume end ``` We have a loop that resumes a fiber, that fiber yields, and then becomes unreachable. Eventually, we will exhaust the OS vm map limit and fail with `FiberError`. However, at most only one fiber (stack) is needed to execute the above program, since the fiber immediately becomes unreachable. To fix this, we run GC before trying to expand the fiber stacks. In practice, fiber stacks are expanded on power of 2, up to 1024 fibers per allocation. So GC is only run in scenarios where we hit this limit. If GC is running normally, or fibers are terminating normally, we may never hit this code path. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125122] [Ruby Feature#8948] Frozen regex
by Eregon (Benoit Daloze) 24 Mar '26

24 Mar '26

Issue #8948 has been updated by Eregon (Benoit Daloze). From the discussion at the dev meeting https://github.com/ruby/dev-meeting-log/blob/master/2026/DevMeeting-2026-01… > matz: try freezing Regexp instances, but no subclasses, and revisit it to check compatibility issues. I will adjust the PR (https://github.com/ruby/ruby/pull/14547) to do that. ---------------------------------------- Feature #8948: Frozen regex https://bugs.ruby-lang.org/issues/8948#change-116842 * Author: sawa (Tsuyoshi Sawada) * Status: Assigned * Assignee: Eregon (Benoit Daloze) * Target version: 4.1 ---------------------------------------- =begin I see that frozen string was accepted for Ruby 2.1, and frozen array and hash are proposed in https://bugs.ruby-lang.org/issues/8909. I feel there is even more use case for a frozen regex, i.e., a regex literal that generates a regex only once. It is frequent to have a regex within a frequently repeated portion of code, and generating the same regex each time is a waste of resource. At the moment, we can have a code like: class Foo RE1 = /pattern1/ RE2 = /pattern1/ RE3 = /pattern1/ def classify case self when RE1 then 1 when RE2 then 2 when RE3 then 3 else 4 end end end but suppose we have a frozen `Regexp` literal `//f`. Then we can write like: class Foo def classify case self when /pattern1/f then 1 when /pattern1/f then 2 when /pattern1/f then 3 else 4 end end end =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124414] [Ruby Bug#21818] Thread backtraces cannot be communicated over Ractor ports
by dazuma (Daniel Azuma) 24 Mar '26

24 Mar '26

Issue #21818 has been reported by dazuma (Daniel Azuma). ---------------------------------------- Bug #21818: Thread backtraces cannot be communicated over Ractor ports https://bugs.ruby-lang.org/issues/21818 * Author: dazuma (Daniel Azuma) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- It looks like Thread::Backtrace is confined to the Ractor that produced it: it cannot be copied or moved to another Ractor, nor can it be made shareable. This makes it difficult for a Ractor to communicate exceptions (e.g. the reason for its own failure) to other Ractors. Is this intentional? I would have expected that a Thread::Backtrace is just static data that should not have problems moving between Ractors. Details below: **Thread::Backtrace cannot be moved to another Ractor** Code: ``` def make_trace caller_locations end r1 = Ractor.new do port = receive trace = make_trace puts "**** Original: #{trace.inspect}" port.send(trace, move: true) # Fails here end port = Ractor::Port.new r1.send(port) trace = port.receive # Hangs here puts "**** Received: #{trace.inspect}" ``` Result: ``` **** Original: ["hello.rb:7:in 'block in <main>'"] #<Thread:0x000000010438f770 run> terminated with exception (report_on_exception is true): hello.rb:9:in 'Ractor::Port#send': can not move Thread::Backtrace::Location object. (Ractor::Error) from hello.rb:9:in 'block in <main>' ``` As a result, it is also not possible to move an Exception: ``` r1 = Ractor.new do port = receive begin raise "hello" rescue => e port.send(e, move: true) # Fails here end end port = Ractor::Port.new r1.send(port) e = port.receive # Hangs here ``` Result: ``` #<Thread:0x0000000102a0f570 run> terminated with exception (report_on_exception is true): hello.rb:6:in 'Ractor::Port#send': can not move Thread::Backtrace object. (Ractor::Error) from hello.rb:6:in 'block in <main>' ``` Note that Kernel#caller returns a string array that can be moved successfully: ``` def make_trace caller end r1 = Ractor.new do port = receive trace = make_trace puts "**** Original: #{trace.inspect}" port.send(trace, move: true) end port = Ractor::Port.new r1.send(port) trace = port.receive puts "**** Received: #{trace.inspect}" ``` Result: ``` **** Original: ["hello.rb:7:in 'block in <main>'"] **** Received: ["hello.rb:7:in 'block in <main>'"] ``` **Thread::Backtrace cannot be *copied* to another Ractor either** Code: ``` def make_trace caller_locations end r1 = Ractor.new do port = receive trace = make_trace puts "**** Original: #{trace.inspect}" port.send(trace, move: false) # Fails here end port = Ractor::Port.new r1.send(port) trace = port.receive # Hangs here puts "**** Received: #{trace.inspect}" ``` Result. Note the specific error message "allocator undefined" that might give a clue why this is all happening: ``` **** Original: ["hello.rb:7:in 'block in <main>'"] #<Thread:0x000000010031f5c8 run> terminated with exception (report_on_exception is true): hello.rb:9:in 'Ractor::Port#send': allocator undefined for Thread::Backtrace::Location (TypeError) port.send(trace, move: false) ^^^^^^^^^^^^^^^^^^ from hello.rb:9:in 'block in <main>' ``` Again, Kernel#caller returns a string array that copies successfully: ``` def make_trace caller end r1 = Ractor.new do port = receive trace = make_trace puts "**** Original: #{trace.inspect}" port.send(trace, move: false) # Fails here end port = Ractor::Port.new r1.send(port) trace = port.receive # Hangs here puts "**** Received: #{trace.inspect}" ``` Result: ``` **** Original: ["hello.rb:7:in 'block in <main>'"] **** Received: ["hello.rb:7:in 'block in <main>'"] ``` Interestingly, if an exception is copied when sent over a port, it doesn't fail with an undefined allocator, but the backtrace in the copy is empty: ``` r1 = Ractor.new do port = receive begin raise "hello" rescue => e puts "**** Original: #{e.backtrace.inspect}" port.send(e, move: false) end end port = Ractor::Port.new r1.send(port) e = port.receive puts "**** Received: #{e.backtrace.inspect}" ``` Result: ``` **** Original: ["hello.rb:4:in 'block in <main>'"] **** Received: [] ``` **Thread::Backtrace cannot be made shareable** Code: ``` def make_trace caller_locations end trace = Ractor.make_shareable(make_trace) # Fails here ``` Result: ``` hello.rb:5:in 'Ractor.make_shareable': can not make shareable object for "hello.rb:5:in '<main>'" (Ractor::Error) from hello.rb:5:in '<main>' ``` As a result, exceptions also cannot be made shareable: ``` begin raise "hello" rescue => e e = Ractor.make_shareable(e) # Fails here end ``` Result: ``` hello.rb: can not make shareable object for #<Thread::Backtrace:0x0000000102fdfe28> (Ractor::Error) ``` Interestingly, if the backtrace is empty, make_shareable succeeds, suggesting that it's specifically the Thread::Backtrace::Location that cannot be made shareable: ``` trace = Ractor.make_shareable(caller_locations) puts trace.inspect ``` Result: ``` [] ``` And, of course, the result of Kernel#caller can be made shareable: ``` def make_trace caller end trace = Ractor.make_shareable(make_trace) puts trace.inspect ``` Result: ``` ["hello.rb:5:in '<main>'"] ``` -- https://bugs.ruby-lang.org/

3 4

[ruby-core:123672] [Ruby Feature#21665] Revisit Object#deep_freeze to support non-Ractor use cases
by headius (Charles Nutter) 24 Mar '26

24 Mar '26

Issue #21665 has been reported by headius (Charles Nutter). ---------------------------------------- Feature #21665: Revisit Object#deep_freeze to support non-Ractor use cases https://bugs.ruby-lang.org/issues/21665 * Author: headius (Charles Nutter) * Status: Open ---------------------------------------- ## Proposal: Introduce `Object#deep_freeze` (or similar name) to freeze an entire object graph I would like to re-propose the addition of Object#deep_freeze as a way to explicitly freeze an entire object graph. This proposal was rejected some years ago after being brought up in https://bugs.ruby-lang.org/issues/17145. The proposal was rejected in favor of making Ractor-specific methods like Ractor.make_shareable. There are a number of reasons why I believe `deep_freeze` is still an important addition: * Rubyists have been requesting a way to deep freeze an object graph for many years (decades?), far longer than Ractor has existed. * Immutable objects are the safest way to safe concurrency, with or without parallel threading or Ractor. * In fact, deep freezing has utility *completely unrelated to concurrency*, such as to guarantee that a large graph of objects will not be modified in the future. * In the absence of `deep_freeze`, users have been forced to implement the behavior themselves, rely on third-party libraries, or call `Ractor.make_shareable` even if they never intend to use Ractor. * The existing `Ractor.make_shareable` primarily does a deep freeze internally. Given the steady move toward making immutability the norm in Ruby, it seems clear to me that deep freezing is a feature that is long overdue. ## Revisiting arguments for rejecting `deep_freeze`: A number of reasons were given in #17145 for preferring the `Ractor.make_shareable` method and rejecting `deep_freeze`. I address those here: @ko1: > One concern about the name "freeze" is, what happens on shareable objects on Ractors. > For example, Ractor objects are shareable and they don't need to freeze to send beyond Ractor boundary. As mentioned above, deep freezing has utility completely separate from Ractors and concurrency. It is a frequently-requested and very useful feature to add. I think we should treat this as a standalone feature, and treat enhancements for Ractors as a separate concern. @ko1: > I also want to introduce Mutable but shareable objects using STM (or something similar) writing protocol (shareable Hash). What happens on deep_freeze? Five years later, I believe this has not yet happened. A potential future optimization for Ractor should not be justification to reject a useful feature today. If users implement their code using primarily immutable objects now, it's unlikely that they will want those same objects to be mutable in the future (this applies to deep freezing as well as `make_shareable`). @eregon: > A dynamic call to freeze causes extra calls, and needs checks that it was indeed frozen. > So for efficiency I think it would be better to mark as frozen internally without a call to freeze on every value. I agree with the concerns about dynamic calls to freeze and overridden versions of the method. It may make more sense to implement this as a utility method, like `Object.deep_freeze(obj)` (a non-overridable class utility method). This is essentially what has been implemented within `Ractor.make_shareable` today. @ko1: > Maybe the author don't want to care about Ractor. > The author want to declare "I don't touch it". So "deep_freeze" is better. This was actually given as a justification for a `deep_freeze` method versus something like `Object#to_shareable`, and yet what we ended up with was a method that requires users know about Ractor. I believe there should be a `deep_freeze` method that has nothing to do with Ractor. And users on JRuby and TruffleRuby already can get full parallelism today without Ractor. They do not care about Ractor, but they definitely care about deep freezing. @eregon: > I don't like anything with "ractor" in the name, that becomes not descriptive of what it does and IMHO looks weird for e.g. gems not specifically caring about Ractor. This is a large part of my justification for revisiting this proposal. Users should not have to care about or want to use Ractor just so they can deep freeze an object graph, because it has utility far beyond Ractor. @ko1: > I implemented Object#deep_freeze(skip_shareable: false) for trial. > https://github.com/ko1/ruby/pull/new/deep_freeze There's already a prototype of this, though I suspect this logic essentially became `Ractor.make_shareable` in the end. I believe it would be acceptable to implement `Ractor.make_shareable` by calling `deep_freeze` since there's largely no difference in visible behavior (other than Ractor-specific optimizations like marking a whole graph as shareable). @eregon: > How about first having deep_freeze that just freezes everything (except an object's class)? This is a good proposal. I believe it is what 99% of users currently calling `make_shareable` actually want, and again there's utility well beyond Ractor and concurrency scenarios. @eregon: > So we could mark as deeply frozen first, and remember to undo that if we cannot freeze some object. > However, is there any object that cannot be frozen? I would think not. The majority of uses of `make_shareable` I have seen are called exactly once on a graph of objects. It does not seem to be typical to repeatedly call `make_shareable`. I understand the desire to have a `shareable` bit for Ractor optimization, but that is a *separate feature* from deep freezing an object graph. There are many cases where we will only call `deep_freeze` once to ensure a graph is fully frozen before publishing it for other code to see, and most of these cases will not try to re-deep-freeze that graph. Ractor's need to "double-check" shareability is orthogonal to the discussion about deep freezing and should not be justification for rejecting `deep_freeze`. @eregon brought up concerns about not calling the custom `freeze` method on user types, since they may want to eagerly cache some data. I believe that discussion is out of scope. `deep_freeze` would be defined to only free the objects that are directly walkable from a root object, and only setting frozen bits. A new overridable method could be introduced that `deep_freeze` would call if present, but otherwise it should just do fast-path object freeze flag setting. @marcandre: > Looking at def freeze in the top ~400 gems, I found 64 in sequel gem alone, and 28 definitions in the rest 😅. This comment provides a breakdown of custom `freeze` methods and the reasons they are implemented. Again, I believe this is out of scope for the discussion at hand. Forcing objects to "prepare for deep freezing" is a separate consideration that will be very library-specific, since every library may want to prepare in a different way. But they *all* want the ability to recursively mark objects as frozen, which is a runtime-level feature. @ko1: > We discussed about the name "deep_freeze", and Matz said deep_freeze should be only for freezing, not related to Ractor. So classes/module should be frozen if [C].deep_freeze. This is why I proposed a Object#deep_freeze(skip_shareable: true) and Ractor.make_shareable(obj). Avoiding classes and modules when deep freezing seems like a reasonable option to me. Naming could make this behavior clear, but again I believe 99% of users just want a plain old object `deep_freeze`. And this is again conflating two separate concerns: * deep freezing * marking an entire graph as shareable These are – and should be – two separate features. The deep freezing feature should not depend on setting shareability bits, since shareability is only meaningful in the context of Ractors. @ko1: > So naming issue is reamained? > > Object#deep_freeze (matz doesn't like it) > Object#deep_freeze(skip_sharable: true) (I don't know how Matz feel. And it is difficult to define Class/Module/... on skip_sharable: false) > Ractor.make_shareable(obj) (clear for me, but it is a bit long) > Ractor.shareable!(obj) (shorter. is it clear?) > Object#shareable! (is it acceptable?) > ... other ideas? I outline some alternatives below. ## Alternative forms: @matz didn't like `deep_freeze` five years ago. How do you feel about it now, @matz? Some alternatives with justification: * Object.deep_freeze(obj) This would make sense to avoid users being able to override the `deep_freeze` behavior, and would make it feel more like a global utility method with special behavior. * Object#freeze(obj, deep: true) * Object#freeze(obj, recursive: true) These work within the existing `freeze` method and still convey intent, but may break APIs that don't expect to receive keyword arguments. And there are some alternative names, which may work as either instance methods or class methods: * `freeze_recursive` * `freeze_all` * `freeze!` * `freeze_reachable_objects` (long but a variation of this might address concerns about not freezing classes and modules) -- https://bugs.ruby-lang.org/

6 8

[ruby-core:123881] [Ruby Bug#21703] RUBY_CRASH_REPORT does not work when shelling out in some cases
by peterzhu2118 (Peter Zhu) 24 Mar '26

24 Mar '26

Issue #21703 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21703: RUBY_CRASH_REPORT does not work when shelling out in some cases https://bugs.ruby-lang.org/issues/21703 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.2: DONTNEED, 3.3: REQUIRED, 3.4: REQUIRED ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/15292 RUBY_CRASH_REPORT does not work in some cases when shelling out on Linux. For example, given the following shell script dump.sh: ```sh #!/usr/bin/env bash cat > /tmp/crash ``` And we see it fails like this: ``` $ RUBY_CRASH_REPORT="|dump.sh" ruby -rfiddle -e "Fiddle::Pointer.new(1, 10)[0]" cat: -: Resource temporarily unavailable ``` -- https://bugs.ruby-lang.org/

3 3

[ruby-core:124417] [Ruby Bug#21819] A Data object should be frozen even if it has no members
by dazuma (Daniel Azuma) 24 Mar '26

24 Mar '26

Issue #21819 has been reported by dazuma (Daniel Azuma). ---------------------------------------- Bug #21819: A Data object should be frozen even if it has no members https://bugs.ruby-lang.org/issues/21819 * Author: dazuma (Daniel Azuma) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [arm64-darwin25] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Data objects with at least one member are currently automatically frozen on construction, and shareable if all members are shareable. However, a Data object with no members is not frozen on construction. I would expect such an object similarly to be frozen (and also shareable since it has no non-shareable members). ``` Foo = Data.define(:foo) Foo.new(1).frozen? # => true Bar = Data.define Bar.new.frozen? # => false ``` -- https://bugs.ruby-lang.org/

4 3

[ruby-core:124388] [Ruby Bug#21814] 0.pow(2,-9999999999999999990) should be zero
by matz (Yukihiro Matsumoto) 24 Mar '26

24 Mar '26

Issue #21814 has been reported by matz (Yukihiro Matsumoto). ---------------------------------------- Bug #21814: 0.pow(2,-9999999999999999990) should be zero https://bugs.ruby-lang.org/issues/21814 * Author: matz (Yukihiro Matsumoto) * Status: Open * Target version: 4.0 * ruby -v: 4.1dev * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- When I try `0.pow(2,-9999999999999999990)`, irb prints `-9999999999999999990`, but I think no matter what you divide zero by, the modulo should be zero. Matz. -- https://bugs.ruby-lang.org/

5 4