- ruby-core - ml.ruby-lang.org

[ruby-core:126887] [Ruby Misc#22394] DevMeeting-2026-10-07
by hsbt (Hiroshi SHIBATA) 30 Sep '26

30 Sep '26

Issue #22394 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Misc #22394: DevMeeting-2026-10-07 https://bugs.ruby-lang.org/issues/22394 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/10/07 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2026/10/04. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126890] [Ruby Feature#22395] RubyVM::InstructionSequence.load_from_binary: to optionally accept `file` and `path` arguments
by byroot (Jean Boussier) 30 Sep '26

30 Sep '26

Issue #22395 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22395: RubyVM::InstructionSequence.load_from_binary: to optionally accept `file` and `path` arguments https://bugs.ruby-lang.org/issues/22395 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context I'm trying to fix the long standing [Feature #17593] issue. In short, ISeq caching has a problematic limitation that the path and realpath of the source file is embedded in the iseq. Meaning that if you build your application in a different path than where you later run it, the iseq cache becomes invalid, which is very problematic for some build systems like buildpacks. [Feature #17593] proposed for `load_iseq_eval` to override these paths, but that would mean mutating or duping the iseq which I think would either be dangerous or inneficient. Hence I think to solve that issue we need some change to the public API. ### Proposed changes Change: ```ruby RubyVM::InstructionSequence.load_from_binary(binary) → iseq ``` to: ```ruby RubyVM::InstructionSequence.load_from_binary(binary [, file[, path]]) → iseq ``` These optional parameters are consistent with `ISeq.compile`. Consequently, `VALUE rb_iseq_load_from_binary(const char *ptr, size_t len)` that was introduced in [Feature #22222] (hence not yet released) would become: `VALUE rb_iseq_load_from_binary(const char *ptr, size_t len, VALUE file, VALUE path)`. ### Proposed patch https://github.com/ruby/ruby/pull/18924 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126659] [Ruby Bug#22306] Ruby::Box: with_jit hooks do not reach existing boxes
by hsbt (Hiroshi SHIBATA) 30 Sep '26

30 Sep '26

Issue #22306 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22306: Ruby::Box: with_jit hooks do not reach existing boxes https://bugs.ruby-lang.org/issues/22306 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-10T03:20:50Z master fe58143f12) +YJIT +MN +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Under `RUBY_BOX=1`, enabling YJIT does not switch `Array#each`, `#map`, `#select` and `Integer#downto` to their Ruby implementations in the root and main boxes. Only boxes created later get them. ``` $ RUBY_BOX=1 ruby --yjit -e 'p Array.instance_method(:each).source_location, Ruby::Box.new.eval("Array.instance_method(:each).source_location")' nil ["<internal:array>", 219] ``` Without `RUBY_BOX` the first line is `["<internal:array>", 219]`. 4.0.6 gives the same output. `TestYJIT#test_yjit_option_uses_array_each_in_ruby` and `#test_yjit_enable_replaces_array_each` fail under `RUBY_BOX=1` for this reason. `with_jit` in `jit_hook.rb` registers its block while the builtins load in the master box, so the `undef` and `def` in it change only the master box. The hooks run after the root and main boxes exist, even with `--yjit` (`ruby.c:1877`). By then loading RubyGems has given both boxes their own copy of `Array`, as any cached method call on it does. Moving the hook call before the boxes are created would cover only `--yjit`, not `RubyVM::YJIT.enable`. I see two designs. The first runs the hooks in every existing box as well as the master box when a JIT is enabled. Each box would then check `rb_builtin_basic_definition_p` against its own definitions, so a box that patched `Array#each` keeps its patch. The blocks take their box from their environment, so this needs a way to run them with another box as the current one. The second stops redefining methods after boot. The Ruby implementations are defined at boot next to the C ones, before any box exists, and the JIT picks the Ruby one when it compiles a call. Nothing changes after boot, which fits a master box that runs no code. It does change how the JIT dispatches these methods and what `source_location` reports. `with_yjit` came with 478e0fc710b, when the Ruby `Array#each` from #20182 was limited to YJIT, and became `with_jit` for ZJIT in 2cd10de3309. Both predate Ruby::Box. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126653] [Ruby Bug#22305] Ruby::Box: statically linked prism loads in only one box
by hsbt (Hiroshi SHIBATA) 30 Sep '26

30 Sep '26

Issue #22305 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #22305: Ruby::Box: statically linked prism loads in only one box https://bugs.ruby-lang.org/issues/22305 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-10T03:20:50Z master fe58143f12) +YJIT +MN +PRISM [arm64-darwin27] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Under `RUBY_BOX=1`, the statically linked prism can be required in only one box. The second box raises `LoadError`. ``` $ RUBY_BOX=1 ruby --disable-gems -e 'require "prism"; p Ruby::Box.new.eval(%q{require "prism"; Prism::VERSION})' lib/prism.rb:161:in 'Kernel#require': cannot load such file -- prism/prism (LoadError) ``` Swapping the order fails the same way. `--disable-gems` matters here. With a prism gem installed, each box dlopens its own copy of the gem's `prism.bundle` and the problem disappears, which makes it easy to miss. There is no `prism.so` file. `prism_init.c:8` registers the name `prism/prism.so` with `ruby_init_ext`, pointing at the `Init_prism` already linked into the interpreter, so `require "prism/prism"` behaves as if it had loaded an extension. That entry can be used only once (`load.c:1280`). The parser itself works in every box, but loading a gem that requires prism internally, such as error_highlight, is enough to break it in every box other than the one that loaded prism first. The obvious fixes do not hold. Running the init in every box leaves one set of C globals pointing at whichever box ran it last, so nodes parsed in the other box fail `is_a?(Prism::ProgramNode)`. That trades the `LoadError` for a silent type mismatch. Initializing prism before the boxes exist and marking the feature provided makes the `require "prism/prism"` inside an activated prism gem a no-op, so the gem's Ruby half binds to the interpreter's C half. The `ruby-lsp` benchmark fails on exactly that. I see three designs and would like one chosen. The first treats prism as an extension. The Ruby binding is built as its own shared object while the parser stays static, so each box dlopens its own copy the way it already does for other extensions. The same principle would also fix every extension under `--with-static-linked-ext`. It changes the build and needs symbol exports on Windows. The second treats it as part of the interpreter, like `String`. It is initialized once before the boxes and every box shares its classes. `defined?(Prism)` becomes true without a `require`, it adds 339 classes at boot, and a prism gem can no longer take over. The third changes Box instead. One way would be to share a statically linked extension across boxes like a builtin class without marking it provided, so that a prism gem can still take over, though I am not sure that fits where Box is heading. ## How prism came to ship this way #19741 mirrored YARP into ruby/ruby together with its Ruby API and registered the native part with `ruby_init_ext`. #19772 then moved toward mirroring only the C implementation and leaving the Ruby API to a bundled prism gem (#19772#note-29), and #19900 stated that prism would be a bundled gem with a native extension. The static registration from #19741 survived the rename, so prism ships as a default gem linked into the interpreter, and that registration is what fails here. The native extension #19900 described works in every box, and the first design comes down to it. The second design has a history of its own. Matz first approved a built-in `Ruby::Parser` that no gem could replace (#19772#note-9), and the same idea came back as a gem-independent `Ruby::Node` for `Proc#syntax_tree` (#21795#note-1). There Matz required that the parser that ran the program and the parser that returns the tree be the same (#21795#note-19), and the feature settled on the default gem prism for that. That is exactly the prism a second box cannot load, which also blocks the way #21795#note-38 suggested Box could eventually expose the interpreter's own parser. -- https://bugs.ruby-lang.org/

1 1

[ruby-core:126880] [Ruby Bug#22390] ruby 3.4 -> 4.0 upgrade GC changes causing >2x RSS increase
by chucke (Tiago Cardoso) 30 Sep '26

30 Sep '26

Issue #22390 has been reported by chucke (Tiago Cardoso). ---------------------------------------- Bug #22390: ruby 3.4 -> 4.0 upgrade GC changes causing >2x RSS increase https://bugs.ruby-lang.org/issues/22390 * Author: chucke (Tiago Cardoso) * Status: Open * ruby -v: 4.0.6 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I've been trying to upgrade a fairly sizeable monolith, which has been running on ruby 3.4.10 in production, to ruby 4 (have been targeting 4.0.6 more specifically, although the below should apply the same to 4.0.7). While we didn't experience anything out of the ordinary in staging, unfortunately, we started seeing our more intensive workloads (job processors) grow in memory usage over the first 40m of running on ruby 4, up to the point where the servers would hit OOM, at which point we decided to rollback and investigate. This workload calls `Process.warmup` after booting the application and then fork multiple processes (not sure if this information is relevant). We figured out that the culprit of this change in GC behaviour was [this commit](https://github.com/ruby/ruby/commit/d4406f0627c78af31e61f9e07dda915… from @peter.zhu; this commit actually another bug for which we have a mitigation in ruby 3.4, however it changed quite a few more things in the heuristics used to decide when to give empty pages back to the OS. Before the commit, `heap_pages_free_unused_pages` used `objspace->heap_pages.allocatable_slots` to decide, and this number would be reset to 0 on every sweep, and grow when expanding the heap, which resulted in every empty page being freed on every major GC. After the commit, this changed to using `heap_pages_freeable_pages`, which gets computed on every major GC, and matched against GC_HEAP_FREE_SLOTS_MAX_RATIO. In our case at least, this doesn't work out, because in the aforementioned workload, `objspace_available_slots` grows at the same pace as `heap_pages_freeable_pages`; this makes it so that the 65% max ratio is never reached for this type of steadily churning live sets; by the time the size pools settle, the remainder of empty pages is never given back. I also tried to pull claude to figure some of this out, and it mentioned that the per pool 20% reservation alongside the single (per process) empty pages management somehow plays a role, but I couldn't make sense of whether that was legit or just an hallucination. I'm attaching a script which I coded with some AI help to roughly mimic the objects being created per job iteration. Bear in mind that, in our case in production, we're talking about many more (OOM hits at ~5Gb, and we've seen the ruby 4 builds grow up to 4Gb before we rolled back), but this represents the type of objects created in a way that makes each of the pools grow independently. If you run it locally, you should see the ruby 4 example use ~2x the memory, mostly because of the empty pages being kept around; major gcs will sometimes free them back to the OS, but I suspect that the reason for it was some other condition triggering a major GC (oldmalloc perhaps?) and causing `heap_pages_freeable_pages` to be recalculated as a result. We continue experimenting with the GC knobs to see if we can find a combination which would allow us to run ruby 4 in production. We're looking at pre-allocating a bunch of slots in pools 1-5 (as per upper bounds from observations using `GC.stat_heap`), while lowering GC_HEAP_OLDOBJECT_LIMIT_FACTOR to force major GC to run more often (a tad more, not too much, not to hurt latency) and hopefully updating freeable pages stats, while also lowering GC_HEAP_FREE_SLOTS_MAX_RATIO as well to a value that makes more sense. If anyone has suggestions on how to further get to optimal values, I'm all ears. Still, while I accept that special workloads require special tuning, I don't find this one unusual enough to justify this type of memory usage increase just due to a ruby upgrade, hence why I file this as a bug. ---Files-------------------------------- repro_gc.rb (4.56 KB) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126884] [Ruby Bug#22393] Backport bf937bfa16767a4dd857ee16f4f18df1bae4d5ca - Fix memory leak on compile error in a later branch of an alternation
by sethuarun (Sethupathi Arunachalam) 30 Sep '26

30 Sep '26

Issue #22393 has been reported by sethuarun (Sethupathi Arunachalam). ---------------------------------------- Bug #22393: Backport bf937bfa16767a4dd857ee16f4f18df1bae4d5ca - Fix memory leak on compile error in a later branch of an alternation https://bugs.ruby-lang.org/issues/22393 * Author: sethuarun (Sethupathi Arunachalam) * Status: Open * ruby -v: ruby 4.0.6 (2026-07-14 revision 03b6d3f889) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- please backport this to Ruby 4! Ruby 3 is unaffected. Commit: bf937bfa16767a4dd857ee16f4f18df1bae4d5ca PR https://github.com/ruby/ruby/pull/19026 Original ticket: 22384 -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126883] [Ruby Feature#22392] Allow refinements to define && and ||
by shugo (Shugo Maeda) 30 Sep '26

30 Sep '26

Issue #22392 has been reported by shugo (Shugo Maeda). ---------------------------------------- Feature #22392: Allow refinements to define && and || https://bugs.ruby-lang.org/issues/22392 * Author: shugo (Shugo Maeda) * Status: Open * Target version: 4.1 ---------------------------------------- ## Abstract I propose to allow refinements to define `&&` and `||`, so that DSLs can build expressions such as `name == "x" && age > 20`. The right-hand side is evaluated before the method is called, so short-circuiting is not customizable. ## Motivation Query builders and similar DSLs want to capture boolean expressions written in a block: ```ruby User.where { name == "x" && age > 20 } ``` Today such DSLs have to use `&` and `|` instead, which bind tighter than `==` and `>`, so every operand needs parentheses: `(name == "x") & (age > 20)`. ## Proposal `&&` and `||` can be defined as methods in refinements: ```ruby module QueryDSL refine Condition do def &&(other) = And.new(self, other) def ||(other) = Or.new(self, other) end end def User.where(&block) = build(block.refined(QueryDSL).call) User.where { name == "x" && age > 20 } # => And(Eq(name, "x"), Gt(age, 20)) ``` Semantics of `a && b` (`a || b` is symmetric): * If the class of `a` has `&&` defined by a refinement active in the current scope, `b` is evaluated and `a.&&(b)` is the result. * Otherwise, the behavior is unchanged. With a hook, the result is always `a.&&(b)`, which never short-circuits. Details: * `&&` and `||` can be defined only in refinements. Defining them elsewhere raises NameError. A hook changes when the right-hand side is evaluated, so its effect should be limited to code that opted in by `using` or `Proc#refined`, rather than reaching every method that receives such an object. There are no default methods such as `Object#&&`, so `super` is not available in a hook. * The hooks also apply in conditions such as `if a && b`, so that `x = a && b; if x` and `if a && b` behave the same. * `and` and `or` behave the same as `&&` and `||`. * `&&=` and `||=` do not use the hooks, to keep the memoization idiom. * `def &&`, `def ||`, `:&&` and `:||` become valid syntax. ## Prior art Scala and Swift treat `&&` and `||` as ordinary methods, so DSLs such as Slick define them on their own types, and the compiler resolves them statically. C# lets a type define `&`, `|`, `true` and `false`, and expands `x && y` to `T.false(x) ? x : x & y`. C++ allows overloading `&&` globally, which is discouraged because short-circuiting is lost for every user of the type. Python, Kotlin, Rust and Julia don't allow it; their DSLs use `&` and `|` with the same precedence problem as in Ruby, and PEP 335, which proposed overloadable `and`/`or`, was rejected for the cost it added to every `and`/`or` and for its complexity. This proposal follows Scala and Swift in dispatching on the receiver, at run time since Ruby is dynamically typed, and limits the definitions to refinements so that, unlike in C++, code outside the DSL keeps short-circuiting. Code that doesn't use the hooks pays nothing, unlike in PEP 335. The right-hand side is evaluated eagerly rather than passed lazily: a hook that builds an expression needs its value in any case, so laziness would add complexity without a use. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126882] [Ruby Bug#22391] Fix propagation of `ERRNO` in `rb_io_maybe_wait`.
by ioquatix (Samuel Williams) 29 Sep '26

29 Sep '26

Issue #22391 has been reported by ioquatix (Samuel Williams). ---------------------------------------- Bug #22391: Fix propagation of `ERRNO` in `rb_io_maybe_wait`. https://bugs.ruby-lang.org/issues/22391 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- When a write returns `EAGAIN`, we call `rb_io_wait()`: io_write() io_fwrite() io_binwrite() io_binwrite_string() io_binwrite_string_internal() ... rb_io_maybe_wait_writable() rb_io_maybe_wait() return rb_io_wait(io, events, timeout) if this wait also fails, it bubbles up to io_write() which reports it: io_write() rb_sys_fail_on_write() rb_syserr_new_path_in() rb_syserr_new_path(errno, ...) `rb_syserr_new_path_in` (after macro resolution) checks for a 0 error code and aborts in that case: if (n == 0) { const char *s = !NIL_P(path) ? RSTRING_PTR(path) : ""; if (!func_name) func_name = "(null)"; rb_bug("rb_sys_fail_path_in(%s, %s) - errno == 0", func_name, s); } Unfortunately, `rb_io_wait()` can invoke the fiber scheduler, running arbitrary code that can clobber `errno` and trigger this `rb_bug()`. Fix this by preserving `errno` explicitly across the `rb_io_wait()` call. https://github.com/ruby/ruby/pull/19121 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126879] [Ruby Bug#22389] Hang on GC.compact
by rkh (Konstantin Haase) 29 Sep '26

29 Sep '26

Issue #22389 has been reported by rkh (Konstantin Haase). ---------------------------------------- Bug #22389: Hang on GC.compact https://bugs.ruby-lang.org/issues/22389 * Author: rkh (Konstantin Haase) * Status: Open * ruby -v: ruby 4.1.0dev (2026-09-29T07:26:07Z master 64a4a372d7) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- The following code works on 4.0.7 but hangs on 4.1.0dev (64a4a372d7): ```ruby ready = Ractor::Port.new Ractor.new(ready) do |port| Array.new(10_000) { Object.new } port << true Ractor.receive end ready.receive Thread.new { GC.compact }.join GC.compact ``` A native sample of the hung process shows: ```text gc_start_global gc_compact_finish gc_update_references_heap rb_iseq_mark_and_move rb_gc_mark_and_move rb_gc_impl_location + 180 ``` -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126878] [Ruby Bug#22388] Use-after-free when an Enumerable retains its `each` block
by nobu (Nobuyoshi Nakada) 29 Sep '26

29 Sep '26

Issue #22388 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22388: Use-after-free when an Enumerable retains its `each` block https://bugs.ruby-lang.org/issues/22388 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.3: REQUIRED, 3.4: REQUIRED, 4.0: REQUIRED ---------------------------------------- Some `Enumerable` methods pass a pointer to stack-allocated state to `rb_block_call`. If an implementation of `each` retains the given block and invokes it after the `Enumerable` method has returned, the callback accesses invalid stack memory. This affects `Enumerable#min(n)`, `#max(n)`, `#min_by(n)`, and `#max_by(n)`. It also affects `Enumerable#sum`. The following example reproduces the problem: ````ruby class DeferredEach include Enumerable attr_reader :each_block def each(&block) @each_block = block end end enum = DeferredEach.new enum.min(2) GC.start enum.each_block.call(1) ```` The same problem exists in the other methods: ````ruby %i[min max min_by max_by].each do |method| enum = DeferredEach.new enum.public_send(method, 2) { |x| x } GC.start enum.each_block.call(1) end ```` `Enumerable#sum` can be reproduced as follows: ````ruby enum = DeferredEach.new enum.sum { |x| x * 2 } GC.start enum.each_block.call(1) ```` Depending on the stack contents and GC timing, these examples may crash, raise an unrelated exception, or appear to work. The behavior is undefined because the retained callback refers to state whose lifetime ended when the original method returned. -- https://bugs.ruby-lang.org/

1 0