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

[ruby-core:124726] [Ruby Feature#21871] Add Module#undef_const
by jeremyevans0 (Jeremy Evans) 28 Apr '26

28 Apr '26

Issue #21871 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #21871: Add Module#undef_const https://bugs.ruby-lang.org/issues/21871 * Author: jeremyevans0 (Jeremy Evans) * Status: Open ---------------------------------------- I propose to add `Module#undef_const`, which would operate for constants similarly to how `undef_method` (and the `undef` keyword) works for methods. When an undefed constant is found during constant lookup, lookup stops, and results in `const_missing` being called (similar to how `undef_method` stops method lookup and results in `method_missing` being called). The expected use for this is for stopping direct access to global constants inside namespaces. For example: ```ruby class DangerousClass; end class SafeClass undef_const :DangerousClass DangerousClass # NameError (const_missing behavior) end DangerousClass # no error ``` You cannot implement this behavior without introducing the equivalent of `Module#undef_const`. The best you can do is define a constant in the namespace that raises later when there is some access to the returned object. However, that approach has significant limitations, since you cannot raise on the lookup, only later when something operates on the returned object: ```ruby class DangerousClass; end class SafeClass DangerousClass = BasicObject.new DangerousClass.foo # NoMethodError DangerousClass::Constant # TypeError def m # doesn't raise, NoMethodError/TypeError occurs potentially much later in unrelated code [DangerousClass] end end ``` As to why it is good to stop direct access to a particular constants inside a namespace, it helps avoid IDOR (insecure direct object reference) security issues, since it pushes you to use a style like: ```ruby # Find a bar related to this foo bar = foo.bars.find { it.id == some_id } ``` As opposed to: ```ruby bar = Bar.find { it.id == some_id && it.foo.id == foo.id } ``` Assuming these are equivalent, the first approach is still better, because it avoids the possibility that a developer can write the following, missing the necessary check that the bar being accessed is related to the foo: ```ruby bar = Bar.find { it.id == some_id } ``` By using `undef_const :Bar` in the namespace, the `Bar.find` approach will not work, and developers will be pushed to use the `foo.bars.find` approach, which enforces safer behavior. I've submitted a pull request that implements this proposal: https://github.com/ruby/ruby/pull/16116 -- https://bugs.ruby-lang.org/

4 4

[ruby-core:124864] [Ruby Misc#21922] Permissions for committers for default/bundled/unbundled gems repositories
by Eregon (Benoit Daloze) 21 Apr '26

21 Apr '26

Issue #21922 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Misc #21922: Permissions for committers for default/bundled/unbundled gems repositories https://bugs.ruby-lang.org/issues/21922 * Author: Eregon (Benoit Daloze) * Status: Open ---------------------------------------- I noticed recently that the team `ruby-committers` on GitHub no longer has write access to at least: * https://github.com/ruby/benchmark * https://github.com/ruby/cmath * https://github.com/ruby/curses * https://github.com/ruby/dbm * https://github.com/ruby/e2mmap * https://github.com/ruby/gdbm * https://github.com/ruby/getoptlong * https://github.com/ruby/iconv * https://github.com/ruby/mathn * https://github.com/ruby/mutex_m * https://github.com/ruby/net-ftp * https://github.com/ruby/net-pop * https://github.com/ruby/net-telnet * https://github.com/ruby/observer * https://github.com/ruby/pathname (marked as maintained by @akr but they don't reply on GitHub, there is also an unclear relation with core Pathname [which still hasn't been resolved](https://github.com/ruby/pathname/issues/66) and is causing warnings for months) * https://github.com/ruby/prime * https://github.com/ruby/pstore * https://github.com/ruby/readline * https://github.com/ruby/readline-ext * https://github.com/ruby/ruby2_keywords * https://github.com/ruby/scanf * https://github.com/ruby/sdbm * https://github.com/ruby/set * https://github.com/ruby/shell * https://github.com/ruby/syck * https://github.com/ruby/sync * https://github.com/ruby/thwait * https://github.com/ruby/tk * https://github.com/ruby/tracer * https://github.com/ruby/webrick * https://github.com/ruby/win32api * https://github.com/ruby/xmlrpc This list is from a couple cases I noticed myself + [all repos](https://github.com/orgs/ruby/repositories?q=mirror%3Afalse+fork%3Afa… - [those committers have access](https://github.com/orgs/ruby/teams/ruby-committers/repositories) - [repos with known maintainers](https://github.com/ruby/ruby/blob/master/doc/maintainers.md)) I filtered manually so there could be some mistake(s), though I tried to check carefully. I am certain CRuby committers had access to some of these repositories (e.g. I merged PRs there), but not sure about all, some might already not have had write access for CRuby committers. It seems only the 4 owners of the Ruby GitHub organization have write access to these repositories. What motivated these changes? I believe it is valuable that all CRuby committers can merge to default/bundled/unbundled gems repositories *without active maintainers*, as it was before. There is [this list](https://github.com/ruby/ruby/blob/master/doc/maintainers.md) to define maintainers, though it's a little bit outdated and inaccurate. It's fine enough for this issue though. (A better definition IMO for active maintainers would be maintainers would actually respond to PRs and issues on GitHub to these repositories otherwise they are effectively not maintaining that repository, at least from an external perspective.) IOW it seems unreasonable to always have to ask one of the 4 owners of the Ruby GitHub organization to merge a PR to such repositories, as it would be a significant overhead for committers and for owners, and it would delay merging PRs significantly. I'm thinking for example to * documentation PRs ([many for pathname](https://github.com/ruby/pathname/pulls)) which really shouldn't need an owner to merge * PRs to improve/fix the CI ([example](https://github.com/ruby/readline-ext/pull/29)) * PRs fixing compatibility with recent changes in ruby's master branch * etc. Yet another way to see this is many default/bundled/unbundled gems do not have active maintainers. AFAIK so far in such cases then all CRuby committers could help, but this seems no longer the case. (FWIW I saw there a `default-gems-contributor` team with 3 people, which explains why they can merge PRs to some repositories that ruby committers can't for example.) -- https://bugs.ruby-lang.org/

6 14

[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: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: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:124634] [Ruby Feature#21852] New improved allocator function interface
by byroot (Jean Boussier) 27 Mar '26

27 Mar '26

Issue #21852 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #21852: New improved allocator function interface https://bugs.ruby-lang.org/issues/21852 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- When implementing native types with the `TypedData` API, You have to define an allocator function. That function receive the class to allocate and is supposed to return a new instance. ```c /** * This is the type of functions that ruby calls when trying to allocate an * object. It is sometimes necessary to allocate extra memory regions for an * object. When you define a class that uses ::RTypedData, it is typically the * case. On such situations define a function of this type and pass it to * rb_define_alloc_func(). * * @param[in] klass The class that this function is registered. * @return A newly allocated instance of `klass`. */ typedef VALUE (*rb_alloc_func_t)(VALUE klass); ``` ### Current API shortcomings There are a few limitations with the current API. #### Hard to disallow `.allocate` without breaking `#dup` and `#clone`. First, it is frequent for extensions to want to disable `Class#allocate` for their native types via `rb_undef_alloc_func`, as very often allowing uninitialized object would lead to bugs. The problem with `rb_undef_alloc_func` is that the alloc func is also used internally by `dup` and `clone`, so most types that undefine the allocator also prevent object copy without necessarily realizing it. If you want to both disable `Class#allocate` yet still allow copying, you need to entirely implement the `#dup` and `#clone` methods, which is non-trivial and very few types do. One notable exception is `Binding`, which has to implement these two methods: https://github.com/ruby/ruby/blob/bea48adbcacc29cce9536977e15ceba0d65c8a02/… This works for Ruby code, however it doesn't work with C-level `rb_obj_dup(VALUE)`, as used by the Ractor logic to copy objects across ractors. In the case of `Binding` we probably wouldn't allow it anyway, but for other types it may be a problem. #### Can't support objects of variable width When duping or cloning an object of variable width, you need access to the original object to be able to allocate the right slot size. An example of that is `Thread::Backtrace` objects, as evidenced by [Bug #21818]. To support sending exception objects across ractors, we'd need to make `rb_obj_dup()` work for `Thread::Backtrace`, but to correctly duplicate a backtrace, the allocator needs to know the size. ### Proposed new API I'd like to propose a new API for defining allocators: ```ruby typedef VALUE (*rb_copy_alloc_func_t)(VALUE klass, VALUE other); ``` In addition to the class to allocate, the function also receives the instance to copy. When called by `Class#allocate`, the `other` argument is set to `Qundef`. Example usage: ```c static VALUE backtrace_alloc(VALUE klass, VALUE other) { rb_backtrace_t *bt; if (UNDEF_P(other)) { // Regular alloc return TypedData_Make_Struct(klass, rb_backtrace_t, &backtrace_data_type, bt); } else { // Copy rb_backtrace_t *other_bt; TypedData_Get_Struct(other, rb_backtrace_t, &backtrace_data_type, other_bt); VALUE self = backtrace_alloc_capa(other_bt->backtrace_size, &bt); bt->backtrace_size = other_bt->backtrace_size; MEMCPY(bt->backtrace, other_bt->backtrace, rb_backtrace_location_t, other_bt->backtrace_size); return self; } } ``` ### Backward compatibility Older-style allocator can keep being supported as long as we wish. The one backward potential compatibility concern is third party code that calls `rb_alloc_func_t rb_get_alloc_func(VALUE klass);`. As its documentation suggest, there's not much valid use case for it, but regardless we can keep supporting it by returning a "jump function". See `copy_allocator_adapter`: https://github.com/ruby/ruby/pull/15795/changes#diff-884a5a8a369ef1b4c7597e… ### Opportunity for more changes? I was discussing this new interface with @ko1 and it appears that the current allocator interface may also be a limitation for Ractors and Ractor local GC. i.e. it might be useful to let the allocator function know that we're copying from one Ractor to another. But I know to little about Ractor local GC to make a proposition here, so I will let @ko1 make suggestions. ### Implementation I implemented this idea in https://github.com/ruby/ruby/pull/15795, to solve [Bug #21818]. It could remain a purely private API, but I think it would make sense to expose it. -- https://bugs.ruby-lang.org/

3 14

[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: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