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

[ruby-core:126268] [Ruby Misc#22230] Should Ruby specs define byte oriented read behavior when the character buffer is not empty?
by javanthropus (Jeremy Bopp) 09 Aug '26

09 Aug '26

Issue #22230 has been reported by javanthropus (Jeremy Bopp). ---------------------------------------- Misc #22230: Should Ruby specs define byte oriented read behavior when the character buffer is not empty? https://bugs.ruby-lang.org/issues/22230 * Author: javanthropus (Jeremy Bopp) * Status: Open ---------------------------------------- In https://github.com/ruby/spec/pull/1384, there was a discussion regarding whether or not raising an IOError when performing a byte oriented read operation while the character buffer is nonempty should be part of the Ruby spec. @eregon asked me to remove the new tests I was requesting to add and also remove existing tests that would define this behavior since it was unclear if the behavior in CRuby was an intentional design decision or a consequence of its specific implementation. I intend to remove the tests in the above MR via a single commit that is easy to revert pending the outcome of this ticket as requested. In all cases I tested, CRuby raises IOError for all byte oriented read operations whenever the character buffer is nonempty. `IO.getc` is used in all these cases to ensure that the character buffer has data in it, but it was argued that other implementations could instead make `getc` reverse the encoding conversion (if one is in play) and put the bytes into the byte buffer instead, eliminating the character buffer entirely. If that conversion would fail, `getc` could raise a conversion error of some kind and leave the buffer unchanged. It's unclear to me though if there are other ways that content could be left in the character buffer during normal read operations which would be harder to avoid while preserving performance and semantics. CRuby's implementation appears to be consistent, so I don't think these tests are attempting to enforce buggy behavior. Should this behavior be codified as part of the spec, or should other implementations be free to behave differently? -- https://bugs.ruby-lang.org/

3 3

[ruby-core:124311] [Ruby Feature#21795] Methods for retrieving ASTs
by kddnewton (Kevin Newton) 08 Aug '26

08 Aug '26

Issue #21795 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Feature #21795: Methods for retrieving ASTs https://bugs.ruby-lang.org/issues/21795 * Author: kddnewton (Kevin Newton) * Status: Open ---------------------------------------- I would like to propose a handful of methods for retrieving ASTs from various objects that correspond to locations in code. This includes: * Proc#ast * Method#ast * UnboundMethod#ast * Thread::Backtrace::Location#ast * TracePoint#ast (on call/return events) The purpose of this is to make tooling easier to write and maintain. Specifically, this would be able to be used in irb, power_assert, error_highlight, and various other tools both in core and not that make use of source code. There have been many previous discussions of retrieving node_id, source_location, source, etc. All of these use cases are covered by returning the AST for some entity. In this case node_id becomes an implementation detail, invisible to the user. Source location can be derived from the information on the AST itself. Similarly, source can be derived from the AST. Internally, I do not think we have to store any more information than we already do (since we have node_id for the first four of these, it becomes rather trivial). For TracePoint we can have a larger discussion about it, but I think it should not be too much work. In terms of implementation, the only caveat I would put is that if the ISEQ were compiled through the old parser/compiler, this should return `nil`, as the node ids do not match up and we do not want to further propagate the RubyVM::AST API. The reason I am opening up this ticket with 5 different methods requested in it is to get approval first for the direction, then I can open individual tickets or just PRs for each method. I believe this feature would ease the maintenance burden of many core libraries, and unify otherwise disparate efforts to achieve the same thing. -- https://bugs.ruby-lang.org/

6 32

[ruby-core:126070] [Ruby Bug#22193] Segmentation fault in functions to MemoryView contiguity with NULL shape and/or strides
by KitaitiMakoto 08 Aug '26

08 Aug '26

Issue #22193 has been reported by KitaitiMakoto (真北市). ---------------------------------------- Bug #22193: Segmentation fault in functions to MemoryView contiguity with NULL shape and/or strides https://bugs.ruby-lang.org/issues/22193 * Author: KitaitiMakoto (真北市) * Status: Open * ruby -v: ruby 4.1.0dev (2026-07-13T13:26:16Z origin/master cb2ea293c6) +PRISM [arm64-darwin25] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Hello, I encountered a segmentation fault when calling `rb_memory_view_is_row_major_contiguous` with a MemoryView whose shape and strides are `NULL`. For instance, a MemoryView initialized with `rb_memory_view_init_as_byte_array` function causes this problem. The cause is that the function handles `shape` and `strides` as arrays without checking whether they are `NULL` or not. Environment ----------- * Ruby commit: cb2ea293c6 * OS: macOS (M2 Mac) Code to reproduce the problem: ------------------------------ I will send a pull request later for the full patch. ### ext/-test-/memory_view/memory_view.c ### ```c static VALUE memory_view_is_row_major_contiguous(VALUE mod, VALUE obj) { rb_memory_view_t view; VALUE result; if (!rb_memory_view_get(obj, &view, 0)) { rb_raise(rb_eArgError, "Unable to get MemoryView"); } result = rb_memory_view_is_row_major_contiguous(&view) ? Qtrue : Qfalse; rb_memory_view_release(&view); return result; } static VALUE memory_view_is_column_major_contiguous(VALUE mod, VALUE obj) { rb_memory_view_t view; VALUE result; if (!rb_memory_view_get(obj, &view, 0)) { rb_raise(rb_eArgError, "Unable to get MemoryView"); } result = rb_memory_view_is_column_major_contiguous(&view) ? Qtrue : Qfalse; rb_memory_view_release(&view); return result; } // ... void Init_memory_view(void) { // ... rb_define_module_function(mMemoryViewTestUtils, "is_row_major_contiguous", memory_view_is_row_major_contiguous, 1); rb_define_module_function(mMemoryViewTestUtils, "is_column_major_contiguous", memory_view_is_column_major_contiguous, 1); // ... } ``` ### test/ruby/test_memory_view.rb ### ```ruby class TestMemoryView < Test::Unit::TestCase # ... def test_rb_memory_view_is_row_major_contiguous es = MemoryViewTestUtils::ExportableString.new("ruby") assert_true(MemoryViewTestUtils.is_row_major_contiguous(es)) end def test_rb_memory_view_is_column_major_contiguous es = MemoryViewTestUtils::ExportableString.new("ruby") assert_true(MemoryViewTestUtils.is_column_major_contiguous(es)) end # ... end ``` Steps to reproduce the problem: ------------------------------- 1. Add code above to the current Ruby (cb2ea293c6) 2. Run `make test-all TESTS=test/ruby/test_memory_view.rb` 3. Then you can see segmentation fault Thank you. -- https://bugs.ruby-lang.org/

1 2

[ruby-core:126329] [Ruby Feature#22236] New API for adjustable JIT warmup
by byroot (Jean Boussier) 08 Aug '26

08 Aug '26

Issue #22236 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22236: New API for adjustable JIT warmup https://bugs.ruby-lang.org/issues/22236 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context YJIT, and probably ZJIT in the near future, do provide a significant latency reduction once warmed up, however, during the warmup phase they tend to cause significant overhead, which temporary degrade the service latency, because of the compilation overhead. Thankfully, ZJIT warmup is fast, but still, for project using continuous delivery, this warmup phase can be restarted several times and hour, and is a bit disruptive. ### Prior Art Currently, the only way to smooth the compilation overhead over time is to adjust `--yjit-call-threshold` which defines how many time a method need to be called before it is considered for compilation. This is useful, but hard to reason about, and can easily be invalidated by code changes. It's also not quite granular enough, because many mehtods are called once per cycle, hence will all become eligible during the same cycle. ### Proposal Since both JITs keep track of how long they spent in the compiler, I propose that they accept an "adjustable compilation time budget". Concretely something like `RubyVM::YJIT.max_compile_time_ns = 1_000_000_000`. - Whenever the JIT is done compiling a block and it increments `RubyVM::YJIT.runtime_stats(:compile_time_ns)`, if `compile_time_ns > max_compile_time_ns` then the JIT disable itself. - Whenever `max_compile_time_ns` is re-assigned, if it's larger than `compile_time_ns` the JIT re-enable itself. ### Expected Use Cases Such API would allow services using one process per request to allocate a compilation budget at the start of a cycle (request, job, etc): ```ruby def call(env) RubyVM::YJIT.max_compile_time_ns = RubyVM::YJIT.runtime_stats(:compile_time_ns) + 20_000_000 # 20ms budget @app.call(env) end ``` For services handling work concurrently, a time based approach can be taken: ```ruby Thread.new do loop do # 20ms budget every 100ms RubyVM::YJIT.max_compile_time_ns = RubyVM::YJIT.runtime_stats(:compile_time_ns) + 20_000_000 sleep 0.1 end end ``` These two example are way easier to reason about than configuring `call-threshold` and don't need frequent re-tuning. ### Considerations This API is meant as best effort. I'm aware that at least YJIT isn't able to full disable compilation, as it leave compilation stubs and have little choice but to compile them when hit. But the "disabled" state doesn't have to be absolute, it simply is a good signal for the JIT to know to delay as much work as possible for later. I also know that JITs don't know how long they'll spend in compilation when they enter it, it's absolutely fine if they go over the set limit slightly, as long as they disable themselves right after. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126328] [Ruby Bug#22235] node_id/location for constant assignment failing while reading
by Eregon (Benoit Daloze) 08 Aug '26

08 Aug '26

Issue #22235 has been updated by Eregon (Benoit Daloze). Status changed from Open to Rejected `NotDefined += 1` also doesn't have a Prism node for the reading part (`name_loc` covers it but that's not a node): ``` ruby -rprism -e 'pp Prism.parse(" NotDefined += 1 ").value' @ ProgramNode (location: (2,0)-(2,15)) ├── flags: ∅ ├── locals: [] └── statements: @ StatementsNode (location: (2,0)-(2,15)) ├── flags: ∅ └── body: (length: 1) └── @ ConstantOperatorWriteNode (location: (2,0)-(2,15)) ├── flags: newline ├── name: :NotDefined ├── name_loc: (2,0)-(2,10) = "NotDefined" ├── binary_operator_loc: (2,11)-(2,13) = "+=" ├── value: │ @ IntegerNode (location: (2,14)-(2,15)) │ ├── flags: static_literal, decimal │ └── value: 1 └── binary_operator: :+ ``` So in general there is no node for the reading part, and `ConstantPathOperatorWriteNode` seems like the exception there. So for consistency I now think it makes sense to use the full assignment/OperatorWriteNode when it fails, even for reading. And differentiating failing while reading or writing must be done with the exception then. It's a little bit unfortunate but I see no good solution, so closing this as rejected since the current state makes sense. Sorry for the noise. Although maybe this will help someone else realize why it is the way it is for `ConstantPathOperatorWriteNode`. ---------------------------------------- Bug #22235: node_id/location for constant assignment failing while reading https://bugs.ruby-lang.org/issues/22235#change-118446 * Author: Eregon (Benoit Daloze) * Status: Rejected * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby namespace = Module.new begin namespace::NotDefined += 1 rescue => e pp e.backtrace_locations[0] pp e.backtrace_locations[0].source_range pp e.backtrace_locations[0].syntax_tree end ``` On CRuby master it gives: ``` $ ruby -v const_assignment_fail_while_reading.rb ruby 4.1.0dev (2026-08-08T08:04:35Z master e56f452e46) +PRISM [x86_64-linux] "const_assignment_fail_while_reading.rb:3:in '<main>'" #<Ruby::SourceRange /.../const_assignment_fail_while_reading.rb:(3,2)-(3,28)> @ ConstantPathOperatorWriteNode (location: (3,2)-(3,28)) ├── flags: newline ├── target: │ @ ConstantPathNode (location: (3,2)-(3,23)) │ ├── flags: ∅ │ ├── parent: │ │ @ LocalVariableReadNode (location: (3,2)-(3,11)) │ │ ├── flags: ∅ │ │ ├── name: :namespace │ │ └── depth: 0 │ ├── name: :NotDefined │ ├── delimiter_loc: (3,11)-(3,13) = "::" │ └── name_loc: (3,13)-(3,23) = "NotDefined" ├── binary_operator_loc: (3,24)-(3,26) = "+=" ├── value: │ @ IntegerNode (location: (3,27)-(3,28)) │ ├── flags: static_literal, decimal │ └── value: 1 └── binary_operator: :+ ``` So even though it's the read failing, it returns the `ConstantPathOperatorWriteNode` and the section is `namespace::NotDefined += 1`. I'm implementing `source_range` & `syntax_tree` on TruffleRuby and there the result is: ``` "const_assignment_fail_while_reading.rb:3:in 'Module#const_missing'" #<Ruby::SourceRange /.../const_assignment_fail_while_reading.rb:(3,2)-(3,23)> @ ConstantPathNode (location: (3,2)-(3,23)) ... ``` So this returns the `ConstantPathNode` and the section is `namespace::NotDefined`. I think TruffleRuby is correct here, especially if we want to differentiate failing while reading or writing. On CRuby it is currently impossible to differentiate because the same node is returned in both cases. (UPDATE: it's possible to differentiate via the exception, but that seems quite brittle. The point is `syntax_tree`&`source_range` should point to the relevant reading node) More information: ``` irb(main):001> namespace = Module.new irb(main):002> namespace::NotDefined += 1 irb(main):003> e=_ irb(main):005> l=e.backtrace_locations[0] irb(main):008> puts RubyVM::InstructionSequence.of(l).disasm == disasm: #<ISeq:<compiled>@(irb):2 (2,0)-(2,26)> 0000 getlocal_WC_1 namespace@0 ( 2)[Li] 0002 dup 0003 putobject true 0005 getconstant :NotDefined 0007 putobject_INT2FIX_1_ 0008 opt_plus <calldata!mid:+, argc:1, FCALL|ARGS_SIMPLE>[CcCr] 0010 swap 0011 topn 1 0013 swap 0014 setconstant :NotDefined 0016 leave irb(main):011> RubyVM::InstructionSequence.of(l).to_a => ["YARVInstructionSequence/SimpleDataFormat", 4, 1, 1, {arg_size: 0, local_size: 0, stack_max: 3, node_id: 6, source_hash: 614720579064667961, code_location: [2, 0, 2, 26], node_ids: [2, 5, 5, 5, 4, 5, 5, 5, 5, 5, 6], parser: :prism}, "<compiled>", "(irb)", nil, 2, :eval, [], {}, [], [2, :RUBY_EVENT_LINE, [:getlocal_WC_1, 3], [:dup], [:putobject, true], [:getconstant, :NotDefined], [:putobject_INT2FIX_1_], [:opt_plus, {mid: :+, flag: 20, orig_argc: 1}], [:swap], [:topn, 1], [:swap], [:setconstant, :NotDefined], [:leave]]] irb(main):013> l.syntax_tree => @ ConstantPathOperatorWriteNode (location: (1,0)-(1,26)) ... ``` The failing instruction must be `getconstant` (BTW, do we have any API to get the insn/insn index for an exception?). That's given `node_id` 5 which is the `ConstantPathOperatorWriteNode`. OK to fix the `node_id` of `getconstant` in such a case to point to the `ConstantPathNode`? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126327] [Ruby Bug#22235] node_id/location for constant assignment failing while reading
by Eregon (Benoit Daloze) 08 Aug '26

08 Aug '26

Issue #22235 has been updated by Eregon (Benoit Daloze). To be complete, the other two "failing while reading" cases in the spec are: (`$` marks the beginning and end of the `source_range`) ```ruby "index operator assignments failing while reading" => <<-RUBY, value = nil $value[0] += 42$ RUBY "attribute operator assignments failing while reading" => <<-RUBY, value = nil $value.foo += 42$ RUBY ``` Those also currently return the write/assignment node, even though it fails while reading. We should probably be consistent there and return the "read node" (`value[0]`/`value.foo`). The trouble there is there isn't such a node in Prism: 1st example, no node with `(3,0)-(3,8)`: ``` $ ruby -rprism -e 'pp Prism.parse(" value = nil value[0] += 42 ").value' @ ProgramNode (location: (2,0)-(3,14)) ├── flags: ∅ ├── locals: [:value] └── statements: @ StatementsNode (location: (2,0)-(3,14)) ├── flags: ∅ └── body: (length: 2) ├── @ LocalVariableWriteNode (location: (2,0)-(2,11)) │ ├── flags: newline │ ├── name: :value │ ├── depth: 0 │ ├── name_loc: (2,0)-(2,5) = "value" │ ├── value: │ │ @ NilNode (location: (2,8)-(2,11)) │ │ └── flags: static_literal │ └── operator_loc: (2,6)-(2,7) = "=" └── @ IndexOperatorWriteNode (location: (3,0)-(3,14)) ├── flags: newline ├── receiver: │ @ LocalVariableReadNode (location: (3,0)-(3,5)) │ ├── flags: ∅ │ ├── name: :value │ └── depth: 0 ├── call_operator_loc: ∅ ├── opening_loc: (3,5)-(3,6) = "[" ├── arguments: │ @ ArgumentsNode (location: (3,6)-(3,7)) │ ├── flags: ∅ │ └── arguments: (length: 1) │ └── @ IntegerNode (location: (3,6)-(3,7)) │ ├── flags: static_literal, decimal │ └── value: 0 ├── closing_loc: (3,7)-(3,8) = "]" ├── block: ∅ ├── binary_operator: :+ ├── binary_operator_loc: (3,9)-(3,11) = "+=" └── value: @ IntegerNode (location: (3,12)-(3,14)) ├── flags: static_literal, decimal └── value: 42 ``` 2nd example, no node with `(3,0)-(3,9)`: ``` ruby -rprism -e 'pp Prism.parse(" value = nil value.foo += 42 ").value' @ ProgramNode (location: (2,0)-(3,15)) ├── flags: ∅ ├── locals: [:value] └── statements: @ StatementsNode (location: (2,0)-(3,15)) ├── flags: ∅ └── body: (length: 2) ├── @ LocalVariableWriteNode (location: (2,0)-(2,11)) │ ├── flags: newline │ ├── name: :value │ ├── depth: 0 │ ├── name_loc: (2,0)-(2,5) = "value" │ ├── value: │ │ @ NilNode (location: (2,8)-(2,11)) │ │ └── flags: static_literal │ └── operator_loc: (2,6)-(2,7) = "=" └── @ CallOperatorWriteNode (location: (3,0)-(3,15)) ├── flags: newline ├── receiver: │ @ LocalVariableReadNode (location: (3,0)-(3,5)) │ ├── flags: ∅ │ ├── name: :value │ └── depth: 0 ├── call_operator_loc: (3,5)-(3,6) = "." ├── message_loc: (3,6)-(3,9) = "foo" ├── read_name: :foo ├── write_name: :foo= ├── binary_operator: :+ ├── binary_operator_loc: (3,10)-(3,12) = "+=" └── value: @ IntegerNode (location: (3,13)-(3,15)) ├── flags: static_literal, decimal └── value: 42 ``` ---------------------------------------- Bug #22235: node_id/location for constant assignment failing while reading https://bugs.ruby-lang.org/issues/22235#change-118445 * Author: Eregon (Benoit Daloze) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby namespace = Module.new begin namespace::NotDefined += 1 rescue => e pp e.backtrace_locations[0] pp e.backtrace_locations[0].source_range pp e.backtrace_locations[0].syntax_tree end ``` On CRuby master it gives: ``` $ ruby -v const_assignment_fail_while_reading.rb ruby 4.1.0dev (2026-08-08T08:04:35Z master e56f452e46) +PRISM [x86_64-linux] "const_assignment_fail_while_reading.rb:3:in '<main>'" #<Ruby::SourceRange /.../const_assignment_fail_while_reading.rb:(3,2)-(3,28)> @ ConstantPathOperatorWriteNode (location: (3,2)-(3,28)) ├── flags: newline ├── target: │ @ ConstantPathNode (location: (3,2)-(3,23)) │ ├── flags: ∅ │ ├── parent: │ │ @ LocalVariableReadNode (location: (3,2)-(3,11)) │ │ ├── flags: ∅ │ │ ├── name: :namespace │ │ └── depth: 0 │ ├── name: :NotDefined │ ├── delimiter_loc: (3,11)-(3,13) = "::" │ └── name_loc: (3,13)-(3,23) = "NotDefined" ├── binary_operator_loc: (3,24)-(3,26) = "+=" ├── value: │ @ IntegerNode (location: (3,27)-(3,28)) │ ├── flags: static_literal, decimal │ └── value: 1 └── binary_operator: :+ ``` So even though it's the read failing, it returns the `ConstantPathOperatorWriteNode` and the section is `namespace::NotDefined += 1`. I'm implementing `source_range` & `syntax_tree` on TruffleRuby and there the result is: ``` "const_assignment_fail_while_reading.rb:3:in 'Module#const_missing'" #<Ruby::SourceRange /.../const_assignment_fail_while_reading.rb:(3,2)-(3,23)> @ ConstantPathNode (location: (3,2)-(3,23)) ... ``` So this returns the `ConstantPathNode` and the section is `namespace::NotDefined`. I think TruffleRuby is correct here, especially if we want to differentiate failing while reading or writing. On CRuby it is currently impossible to differentiate because the same node is returned in both cases. (UPDATE: it's possible to differentiate via the exception, but that seems quite brittle. The point is `syntax_tree`&`source_range` should point to the relevant reading node) More information: ``` irb(main):001> namespace = Module.new irb(main):002> namespace::NotDefined += 1 irb(main):003> e=_ irb(main):005> l=e.backtrace_locations[0] irb(main):008> puts RubyVM::InstructionSequence.of(l).disasm == disasm: #<ISeq:<compiled>@(irb):2 (2,0)-(2,26)> 0000 getlocal_WC_1 namespace@0 ( 2)[Li] 0002 dup 0003 putobject true 0005 getconstant :NotDefined 0007 putobject_INT2FIX_1_ 0008 opt_plus <calldata!mid:+, argc:1, FCALL|ARGS_SIMPLE>[CcCr] 0010 swap 0011 topn 1 0013 swap 0014 setconstant :NotDefined 0016 leave irb(main):011> RubyVM::InstructionSequence.of(l).to_a => ["YARVInstructionSequence/SimpleDataFormat", 4, 1, 1, {arg_size: 0, local_size: 0, stack_max: 3, node_id: 6, source_hash: 614720579064667961, code_location: [2, 0, 2, 26], node_ids: [2, 5, 5, 5, 4, 5, 5, 5, 5, 5, 6], parser: :prism}, "<compiled>", "(irb)", nil, 2, :eval, [], {}, [], [2, :RUBY_EVENT_LINE, [:getlocal_WC_1, 3], [:dup], [:putobject, true], [:getconstant, :NotDefined], [:putobject_INT2FIX_1_], [:opt_plus, {mid: :+, flag: 20, orig_argc: 1}], [:swap], [:topn, 1], [:swap], [:setconstant, :NotDefined], [:leave]]] irb(main):013> l.syntax_tree => @ ConstantPathOperatorWriteNode (location: (1,0)-(1,26)) ... ``` The failing instruction must be `getconstant` (BTW, do we have any API to get the insn/insn index for an exception?). That's given `node_id` 5 which is the `ConstantPathOperatorWriteNode`. OK to fix the `node_id` of `getconstant` in such a case to point to the `ConstantPathNode`? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126326] [Ruby Bug#22234] IO::Buffer#resize(0) copies uninitialized memory into the buffer
by himura467 (Akito Shitara) 08 Aug '26

08 Aug '26

Issue #22234 has been reported by himura467 (Akito Shitara). ---------------------------------------- Bug #22234: IO::Buffer#resize(0) copies uninitialized memory into the buffer https://bugs.ruby-lang.org/issues/22234 * Author: himura467 (Akito Shitara) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Reproduction ```ruby buffer = IO::Buffer.new(64) slice = buffer.slice(0, 8) slice.resize(0) slice.size # => an arbitrary size or a SEGV ``` The outcome depends on what the stack happens to hold. Reading `slice.inspect` instead of `slice.size`, which dereferences `source`, gives either a crash or an unrelated `TypeError` such as `wrong argument type VM/cc_table (expected IO::Buffer)`. A mapped buffer is affected too, on platforms where `mremap` is unavailable (macOS, Windows), and `IO::Buffer.new.resize(0)` is enough to hit it because the 65536 byte default is larger than `PAGE_SIZE`. On Linux that case raises `Errno::EINVAL: Invalid argument - rb_io_buffer_resize:mremap` instead, as `mremap` rejects a zero new length. ## What happens `io_buffer_resize_copy()` fills a stack `struct rb_io_buffer` and then copies it over the live one: ```c struct rb_io_buffer resized; io_buffer_initialize(self, &resized, NULL, size, io_flags_for_size(size), Qnil); ... io_buffer_free(buffer); *buffer = resized; ``` `io_buffer_initialize()` returns without assigning any field when the size is zero, because there is nothing to allocate. `resized` is therefore never initialized, and reading it is already undefined behaviour; all four of `base`, `size`, `flags` and `source` hold indeterminate values once it has been copied over the live buffer. `source` is the dangerous one: it is marked by the GC on every collection, and `io_buffer_validate()` dereferences it as a slice source whenever it is not `Qnil`. `rb_io_buffer_resize()` reaches that path because a slice carries no flag other than `READONLY`, so the `EXTERNAL`, `MAPPED` and `INTERNAL` branches are all skipped. The example above uses an internal source buffer, so no mapping is involved and the platform does not matter. ## Background The `INTERNAL` branch is the only one with a `size == 0` shortcut. It was added by GH-7569 for #19543, where `resize(0)` reached `realloc(base, 0)` and aborted with `[BUG] rb_sys_fail(rb_io_buffer_resize:realloc) - errno == 0`, the null return being taken for an allocation failure. As GH-7569 describes it, glibc frees the object and returns a null pointer for a zero size, while BSDs return an inaccessible object; passing zero to `realloc` is implementation defined in C17 and undefined in C23, so the shortcut keeps it from reaching `realloc` at all. Zero is not a size that any of the allocation APIs behind a buffer can express, and the mapped and slice paths still pass it down. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126238] [Ruby Feature#22227] Per-Ractor GC: collect each Ractor's heap locally, stop the world only when needed
by ko1 (Koichi Sasada) 08 Aug '26

08 Aug '26

Issue #22227 has been reported by ko1 (Koichi Sasada). ---------------------------------------- Feature #22227: Per-Ractor GC: collect each Ractor's heap locally, stop the world only when needed https://bugs.ruby-lang.org/issues/22227 * Author: ko1 (Koichi Sasada) * Status: Open ---------------------------------------- Companion PR: https://github.com/ruby/ruby/pull/18194 --- ## Abstract This proposal makes the default GC operate per Ractor. Each Ractor owns an objspace (a private heap) and collects it on its own thread without stopping any other Ractor ("local GC"). A stop-the-world collection over all objspaces ("global GC") runs only when something genuinely global has to be reclaimed: shareable objects, memory retained across Ractor boundaries, and the heaps of dead Ractors. With this change, allocation-heavy Ractor programs scale like forked processes, and Ractor communication can even beat interprocess communication; end-to-end single-Ractor workloads stay within 2-4% of current performance (focused allocation microbenchmarks move a few percent in both directions, see section 4.4). ## 1. Motivation Today all Ractors allocate from one shared objspace, and every GC stops every Ractor. This has two consequences: 1. GC pause time grows with the total heap of all Ractors, while the pause still stops everyone. N allocating Ractors trigger GCs N times as often, and each GC scans N heaps. 2. The synchronization needed to stop N mutators at every GC dominates as N grows. In practice, a program that parses JSON in 16 Ractors spends 10x the wall clock of its single-Ractor version (for the same per-worker work), while the identical code in 16 forked processes stays at the hardware's parallel limit of about 3.3x. Ractors currently lose to fork exactly on the workloads they were designed for. The root cause is architectural, not incremental: CRuby's current shared objspace couples every Ractor to the same stop-the-world GC. This proposal splits the heap. ## 2. Design overview Terminology used below: * **objspace**: one Ractor's private heap: its pages, freelists, mark stack, generational state and counters. * **local GC**: a collection of a single objspace, run by its owner thread, with no VM lock and no barrier. Other Ractors keep running. * **global GC**: a stop-the-world mark/sweep over all objspaces as one heap. Heap traversal is exact; machine-stack roots remain conservative. * **shareable object**: `Ractor.shareable?(obj) == true` (immutable values, Class/Module, shareable Procs, and so on). * **shref** ("shareable reference"): an unshareable object directly referenced by a shareable one. Details are given in 2.1 and 2.3. ### 2.1 The containment invariant The correctness of a local GC rests on one invariant: > An unshareable object is reachable only from its owner Ractor, except > through edges that the GC has been explicitly told about (shrefs and > in-flight messages). The invariant has an equally important flip side: a **shareable object can be referenced from any Ractor at any time, and nothing records who references it**. A local GC therefore never collects a shareable object, and never even traverses one; it only marks them all as live (2.3). Only a global GC, whose unified mark sees every Ractor's references, can prove a shareable object dead and reclaim it. In other words: unshareable objects are the local GC's responsibility, shareable objects are exclusively the global GC's. Ruby-level Ractor semantics already forbid directly sharing unshareable objects. CRuby, however, has a small number of implementation-level edges that cross the boundary, and the GC work is to make every one of them visible to the collector: * A shareable object can hold an implementation-level reference to an unshareable one: for example, writing through a shareable Proc's environment stores an unshareable value into a shareable env, and a shareable object's hidden instance variables (its fields imemo) can stay unshareable. The **write barrier** detects every such store and records the target as a **shref**. The transition that makes an object shareable likewise registers any pre-existing outgoing edges of this kind (for example, the hidden field values that `Ractor.make_shareable`'s traversal does not reach are shref-recorded at promotion time). * A message in flight (sent, not yet received) lives in the sender's objspace while being reachable only from queue structures. The send path **pins** the payload in the sender's objspace until the receiver materializes it (2.6). Given the invariant, marking one objspace's roots reaches everything a local GC is allowed to free, so a local GC requires no process-wide barrier and never stops another Ractor; its synchronization is confined to leaf mutexes and atomic bitmap operations on shared metadata (2.3). `GC.verify_internal_consistency` walks the heap and checks the invariant edge by edge (builds with `RGENGC_CHECK_MODE` also run it around every collection); it caught most of the bugs found during development. ### 2.2 Heap layout and ownership Every heap page records its owning objspace, so any object's owner is one load away: `GET_HEAP_OBJSPACE(obj)` reads the page header. There is no per-object tag; ownership is a property of the page. Page bodies come from a process-wide **page pool**: large mmap arenas carved into page-sized bodies and recycled through a freelist under a dedicated mutex. Ractors therefore exchange pages (allocation, death, inheritance) without mmap/munmap churn, and without serializing on the kernel's mmap lock. A process-wide **page index** (all pages of all objspaces, sorted by body address) supports the conservative machine-stack scan of a global GC and ownership tests; only stop-the-world code reads it, so it needs no reader lock. Allocation is a bump-pointer fast path (a cursor advancing through free regions) into per-objspace, per-size-class heaps. The upstream per-Ractor newobj cache became unnecessary (the objspace itself is per Ractor), which makes the allocation fast path about 9% faster. ### 2.3 What a local GC does A local GC is the classic incremental/generational collector of CRuby, restricted to one objspace, plus three rules: 1. **Never free a shareable object.** At the end of marking (`gc_marks_finish`), a dedicated pass (`pinned_roots_mark`) marks every shareable object on the objspace's pages that ordinary marking did not reach: mark bit only, no traversal. Another Ractor may hold the only reference to it; only a global GC can prove a shareable object dead. The count of objects kept alive this way is also a useful retention metric (an upper bound on garbage only a global GC can reclaim). 2. **Treat shrefs as roots.** A shref is marked and traversed like a remembered old-to-young target: the shareable parent is never traversed by a local GC (rule 1), so without this its unshareable children would look unreachable. 3. **Never touch a foreign object's GC state.** Marking stops at any object owned by another objspace ("foreign objects are live leaves"): its mark/age/remembered bits belong to its owner, and writing them would race the owner's local GC. Because objects can become shareable at any time between collections, rule 1 scans the shareable/shref bitmaps in every mark cycle rather than trying to maintain a pin set across sweeps. Generational collection stays per objspace. The remembered-set bitmap has exactly one class of cross-thread writers (another Ractor's write barrier remembering a shareable object), and that path uses an atomic bitmap set; everything else is single-writer under the owner's GVL. **Locking model.** A local GC takes neither the VM lock nor any barrier; it never stops or waits for another Ractor. The main Ractor's local GC is the one exception in two bounded windows: it walks VM-global roots and weak tables (`rb_vm_mark`, freeing entries of fstring/symbol/ci tables), which other Ractors rewrite under the VM lock, so it takes a no-barrier VM lock just for those stretches; and when a JIT is enabled, marking reaches JIT payloads of shareable iseqs, which must exclude concurrent compilation. One rule is absolute: a GC must never take the barrier VM lock mid-collection, because the waiter would join a pending global barrier and expose its half-collected heap to the global GC. Shared structures that GC paths touch (page pool, the generic-fields table, registered globals) use their own leaf mutexes instead. **Triggers.** Every local GC entry first asks whether a *global* cycle is needed instead (see 2.4); otherwise the usual malloc/allocation heuristics drive local minor/major cycles per objspace. ### 2.4 What a global GC does A global GC stops the world using the existing barrier mechanism (a GC has no safepoints, so the barrier implicitly waits for every in-flight local GC to finish). Then, with the driver thread executing every phase: 1. **Settle**: finish every objspace's lazy sweep, so mark bits have a single meaning. 2. **Clear**: clear every objspace's mark bits, remembered sets, age metadata and all shref bits. (Missing any of these would leave stale bits and cause use-after-free; this step is why shref bits may only be cleared by a global GC.) 3. **Unified mark**: mark from every Ractor's roots (C-struct roots, machine stacks scanned conservatively against the global page index, VM globals) and traverse exactly, crossing objspace boundaries freely. The write barrier's shref information is re-derived as a byproduct: each shareable-to-unshareable edge encountered re-records the shref bit. In-flight message payloads are re-pinned here (their shref bits were cleared in step 2). 4. **Weak passes**: the generic-fields table (weak keys) is processed to a fixpoint: values (`fields_obj`) of live keys are marked, entries of dead keys are dropped, and since marking a value can make another key live, the pass repeats until no progress. VM-global weak tables (fstring, symbols, call caches and so on) are swept once, not once per objspace. 5. **Sweep**: sweep every objspace inside the barrier (not lazily). This is the only place shareable objects and cross-objspace cycles die. Emptied pages return to the page pool. 6. **Budget**: objspaces left with no free pages get the same heap-growth budget a local full mark would have granted (a global GC bypasses that bookkeeping), so the next allocation does not fail. 7. Shareable-object populations and trigger limits are recounted per objspace. Global GCs are triggered by: an explicit full `GC.start`; growth of the shareable-object population past a per-objspace limit; and accumulation of heap pages held by dead Ractors (see 2.5). Two Ractors deciding to run a global GC at the same time are serialized by the barrier; the second cycle is wasted work, not an error. **Compaction.** With multiple objspaces, `GC.compact` (and autocompact on full marks) runs inside a global GC as three passes over all objspaces: (a) move every objspace's movable objects, leaving forwarding; (b) update references everywhere, following forwarding across objspaces, plus the VM-global side once; (c) sweep and free emptied source pages. It must be three global passes rather than per-objspace work because a reference can point at a moved object in another objspace, and freeing a source page early would let another objspace's update read freed forwarding. A local (non-stop-the-world) compaction runs only while the process has a single objspace; objects that C structs of other Ractors point at (an in-flight payload, a terminated Ractor's pending value) are pinned so they never move even under global compaction. Incremental marking similarly runs only in single-objspace mode; the transition point (`Ractor.new` making the process multi-Ractor) settles any cycle in progress. ### 2.5 Ractor lifecycle and memory hand-off **Creation.** A Ractor's objspace is created before its thread starts, and the child's main Thread and root Fiber wrapper objects are allocated directly into it. Between those allocations and the child joining the Ractor set, the creator "covers" the child objspace through a dedicated slot so a concurrent global GC still enumerates it (an unenumerated objspace would keep stale mark bits). Every failure path of creation (isolation errors, thread-creation failure) hands the child objspace over for reclamation rather than leaking it. **Termination.** A terminating Ractor runs one last local GC with a by-then minimal root set on its own thread ("retire GC": roots are minimal by then, and this reclaims garbage that would otherwise be inherited), and its objspace becomes a **zombie**: registered in a VM-wide table, mutated by nobody, but enumerated by every global GC. Ractor death therefore does not stop the world. **Inheritance.** `Ractor#value` (and join) *absorbs* the dead Ractor's objspace into the caller's: pages are spliced wholesale into the caller's heaps (kept sorted by body address for the conservative scan), the finalizer table entries move over, malloc-accounting counters transfer, and the caller's next collection is forced to a full mark to rebuild generational state. This is why `Ractor#value` can return the value **by reference** with no copy: after the absorb it is an ordinary object of the caller. If a dead Ractor's object is itself collected without ever being joined, its orphan objspace is merged into the main Ractor at main's next safepoint (scheduled as a postponed job, because the discovery happens inside a sweep). At VM shutdown all remaining zombies merge into main so at-exit processing sees every object. Because a zombie's pages still hold shareable objects that other Ractors can reach, zombies participate in the global-GC trigger: accumulated zombie pages past a threshold start a global cycle (measured against what survived the previous one, so a zombie with much live data does not retrigger forever). ### 2.6 Message passing: copy `Ractor#send` (copy semantics) became a two-phase protocol: 1. **Snapshot (sender side).** The sender deep-copies the object graph inside its own objspace using a native copier for core types (String, Array, Hash, Struct, T_OBJECT and so on); types the native copier does not support fall back to a Marshal round trip. `#clone` and `initialize_copy` are never invoked, although Marshal-specific hooks (`marshal_dump`, `_dump`) run on the sender for fallback types and can raise there. Every node of the snapshot is **pinned** in the sender's objspace, and the pin cover is handed off without gaps: from the builder's capture list, to the basket (queue entry), to the receiver's materialization frame. A global GC re-pins from whichever holder is current (its clear pass drops all shref bits, see 2.4 step 2/3). 2. **Materialize (receiver side).** When the receiver takes the message out of the port, it rebuilds the graph inside its own objspace. The sender-resident snapshot becomes garbage once the copy completes. Materialization can raise (Marshal load hooks and autoload run user code; asynchronous interrupts can arrive) and can nest (`Ractor.receive` inside a load hook), so in-progress materializations form a per-EC chain of machine-stack frames that the GC uses as roots. Passing the sender-resident graph to the receiver by reference is never allowed: it would create an unshareable cross-objspace edge that neither local GC could handle. ### 2.7 Message passing: move `Ractor#send(obj, move: true)` serializes the payload graph into an off-heap, malloc-allocated structure called the **courier**. While a moved graph is in flight, there is *no heap object* representing it: neither side's GC can mark, sweep, move, or race with it. * A read-only **preflight** walks the graph first and raises every "can not move" error before anything is mutated (capture is destructive, so failing halfway would corrupt the graph beyond repair). * **Capture** turns each source object into a node in the courier's node array (identity and cycles are preserved through node ids and a by-address dedup table) and immediately neutralizes the source into a `Ractor::MovedObject` shell, without ever passing through an inconsistent state that a concurrent marker could observe. * Payload internals move by ownership transfer where possible: a String that owns its buffer hands the pointer over (zero copy); an IO carries its whole `rb_io_t` including the file descriptor; MatchData dumps its match registers into an onig-independent blob. Shareable references and immediates are carried as values; classes of the moved objects are carried as references (classes are shareable), so subclasses and singleton classes survive the move. * In-flight couriers are registered in a VM-global list; a global GC's root pass marks and pins the shareable references they carry (nothing else roots them in some windows). * **Rebuild** on the receiver allocates all shells first, then fills references (two passes break cycles), and inserts Hash entries last, in reverse id order, so user-defined `#hash` methods observe fully built keys. Rebuilding can raise; an unconsumed courier is freed by the queue teardown, closing descriptor leaks for moved IOs. ### 2.8 Generic instance variables Instance variables of non-T_OBJECT hosts (`str.instance_variable_set` and friends) live in one process-global table keyed weakly by host object, guarded by a dedicated leaf mutex. A local GC reads it per object while marking (it cannot wait for the VM lock there); the global GC processes it in the weak pass described above; per-object cleanup happens when a host is freed. An earlier design with per-Ractor tables plus a shared table was abandoned: entries would have had to migrate on every make-shareable, send and inheritance, and that boundary was a reliable source of bugs. ### 2.9 Modular GC API The GC implementation interface (`gc/gc_impl.h`) gains per-Ractor entry points: `multi_objspace_p`, `objspace_absorb`, `objspace_retire_gc`, `obj_foreign_p`, `during_global_gc_p`, `obj_became_shareable`, `pin_in_flight_message`, `each_objects_shareable`, `each_objects_foreign`, `heap_page_count`, `gc_rest`. An implementation that keeps a single objspace (MMTk) reports `multi_objspace_p() == false` and the VM gates the whole per-Ractor machinery out: every Ractor aliases the one objspace, retire/absorb/zombie handling become no-ops, and Ractor-related marking falls back to following everything from the wrapper objects. MMTk continues to pass its test suite unchanged. ## 3. Compatibility * `Ractor#value` becomes a one-shot ownership transfer: the first call hands the value over by reference together with the dead Ractor's heap, and a second call raises `Ractor::Error` ("The value was already taken"). Returning the same unshareable object again would hand out a reference to an object now owned by the first caller, recreating exactly the cross-Ractor sharing that Ractor semantics forbid; special-casing repeat calls from the same Ractor, or shareable values only, would make the API's behavior depend on the caller and the value's type, so the simple rule was chosen. (Previously repeated calls returned the same object.) * `GC.start` in a multi-Ractor process runs a stop-the-world global GC; automatic GC in a Ractor collects only its own heap. * `GC.disable`/`GC.enable` become per-Ractor holds on a process-wide switch: any Ractor's disable stops automatic GC everywhere, but another Ractor's `GC.enable` no longer silently overrides it. A Ractor's hold is released when it exits. * `ObjectSpace.each_object` enumerates the calling Ractor's own objects plus other live Ractors' shareable objects, never their unshareable ones. Objects of a terminated but not yet inherited Ractor are not enumerated until its heap is absorbed. (`ObjectSpace.dump_all` and `memsize_of_all` still cover every object in the process; they walk the other objspaces under a global barrier.) * `ObjectSpace.define_finalizer` on another Ractor's object raises `Ractor::IsolationError`; finalizers are registered, stored and run in the owner's objspace. * The `RUBY_INTERNAL_EVENT_FREEOBJ` tracepoint fires only for the main Ractor's objspace (it runs user callbacks from inside the sweep, which is unsafe in a lock-free non-main sweep; extending it is future work). * Invalidated call-cache entries are no longer pruned during GC marking; they are reclaimed at the next lookup of that method or when the class dies. Retention is bounded (one entry per class-and-method-id pair); the worst-case microbenchmark retains approximately 2.7 MB for 200,000 stale entries. ## 4. Performance Setup: 16 logical CPUs (8 cores, SMT), x86_64-linux, `-O3` release builds. `master` is the merge-base of the PR, `RLGC` is the branch. Every cell is wall-clock seconds until all N workers finish (lower is better). Because the machine's clock state drifts on multi-minute scales, each RLGC/master pair was measured interleaved back to back, and each number is the minimum over at least 10 runs spread across several sessions. All three programs are weak-scaling benchmarks: every worker runs the full workload independently, so with perfect parallelism the wall clock stays flat as N grows. The ratio tables divide every cell by master-Ractor N=1, i.e. "how many times the wall time of current Ruby running one Ractor"; a perfectly scaling configuration keeps its N=1 ratio at every N. "Ractor" rows run the N workers as Ractors, "fork" rows run the identical code in forked processes: the no-shared-GC baseline that Ractors should match. Scripts are about 40 lines each and attached to the PR. ### 4.1 binary-trees (D=16; allocation/GC-heavy) The classic benchmarks-game workload: each worker builds and checksums millions of short-lived binary trees (3-element arrays). Allocation and GC dominate; objects die young. seconds: | | N=1 | N=2 | N=4 | N=8 | N=16 | |----------------|------|------|------|------|------| | RLGC Ractor | 3.83 | 4.01 | 4.48 | 5.76 | 10.26 | | master Ractor | 3.65 | 4.18 | 5.32 | 8.18 | 14.90 | | RLGC fork | 3.75 | 3.99 | 4.48 | 6.56 | 10.22 | | master fork | 3.66 | 3.90 | 4.40 | 6.40 | 10.03 | ratio (x master-Ractor N=1): | | N=1 | N=2 | N=4 | N=8 | N=16 | |----------------|------|------|------|------|------| | RLGC Ractor | 1.05 | 1.10 | 1.23 | 1.58 | **2.81** | | master Ractor | 1.00 | 1.15 | 1.46 | 2.24 | 4.08 | | RLGC fork | 1.03 | 1.09 | 1.23 | 1.80 | 2.80 | | master fork | 1.00 | 1.07 | 1.21 | 1.75 | 2.75 | RLGC Ractors scale exactly like forked processes (2.81 vs 2.75-2.80 at N=16); master Ractors are 1.45x behind at N=16. For calibration, a zero-allocation pure-integer loop on this machine goes from 5.9s (N=1) to 10.4s (N=16), so RLGC's 10.26s at N=16 is the hardware's SMT ceiling, not a GC limit. ### 4.2 JSON parse (embarrassingly parallel) Each worker parses its own copy of the same ~30 KB JSON document (200 nested user records) 8000 times and discards each result: pure parse-allocate-discard churn, no data crosses workers. This isolates how allocation and GC scale. seconds: | | N=1 | N=2 | N=4 | N=8 | N=16 | |----------------|------|------|------|------|------| | RLGC Ractor | 1.59 | 1.70 | 1.89 | 2.61 | 4.93 | | master Ractor | 1.49 | 2.06 | 2.63 | 5.24 | 15.10 | | RLGC fork | 1.50 | 1.73 | 1.88 | 2.53 | 4.87 | | master fork | 1.48 | 1.64 | 1.81 | 2.48 | 4.94 | ratio (x master-Ractor N=1): | | N=1 | N=2 | N=4 | N=8 | N=16 | |----------------|------|------|------|------|------| | RLGC Ractor | 1.07 | 1.14 | 1.27 | 1.76 | **3.32** | | master Ractor | 1.00 | 1.39 | 1.77 | 3.53 | 10.17 | | RLGC fork | 1.01 | 1.17 | 1.27 | 1.71 | 3.28 | | master fork | 0.99 | 1.10 | 1.22 | 1.67 | 3.33 | master Ractors fall off almost immediately (1.39x already at N=2: every Ractor's allocation churn stops all the others) and end 10x over the baseline at N=16; RLGC matches the fork rows within noise the whole way and finishes 3.1x faster than master Ractors. ### 4.3 JSON producer/consumer (Ractor move vs process IPC) The "coordinator hands work to parsers" pattern: the main Ractor/process produces 20000xN JSON strings (~6 KB each) and distributes them round-robin to N workers, which parse and discard them. The Ractor version transfers each string with `send(move: true)`; the fork version writes it down a pipe (a kernel copy). This measures the data-transfer path, not just parallel GC. seconds: | | N=1 | N=2 | N=4 | N=8 | N=16 | |----------------|------|------|------|------|------| | RLGC Ractor | 0.77 | 0.89 | 1.05 | 1.59 | 2.71 | | master Ractor | 0.71 | 0.99 | 1.68 | 3.87 | 14.59 | | RLGC fork | 0.80 | 0.85 | 0.98 | 1.87 | 3.02 | | master fork | 0.74 | 0.80 | 0.97 | 1.83 | 3.04 | ratio (x master-Ractor N=1): | | N=1 | N=2 | N=4 | N=8 | N=16 | |----------------|------|------|------|------|------| | RLGC Ractor | 1.08 | 1.25 | 1.48 | 2.25 | **3.82** | | master Ractor | 1.00 | 1.40 | 2.37 | 5.45 | 20.55 | | RLGC fork | 1.12 | 1.19 | 1.39 | 2.63 | 4.25 | | master fork | 1.04 | 1.12 | 1.37 | 2.58 | 4.29 | At N=16 RLGC's `move` beats even process IPC (2.71s vs 3.02-3.04s: no kernel copy), while master Ractors are 5.4x behind it. The off-heap courier costs ~8% over master's in-heap move at N=1 (0.77 vs 0.71); that is the price of making in-flight messages invisible to both sides' GCs, and a zero-copy fast path remains possible future work. ### 4.4 Single-Ractor performance Measured with no `Ractor.new` at all (the N=1 rows above already run one worker Ractor, which puts the process in multi-Ractor mode). The allocation fast path itself got faster: the per-Ractor newobj cache is gone and objects come straight off the objspace's bump-pointer heaps. | single Ractor, interleaved minima | RLGC | master | | |---------------------------------------|------|--------|------| | `Object.new` x 20M, GC disabled | 1.83 | 2.01 | **-9%** | | `Object.new` x 20M, GC enabled | 1.18 | 1.10 | +7% | | binary-trees (D=16) | 3.79 | 3.71 | +2% | | JSON parse (8000 docs) | 1.55 | 1.49 | +4% | (`Object.new` rows subtract the loop-only baseline of 0.24s.) Pure allocation wins by 9%; sweep-time bitmap maintenance (the shareable and shref bitmaps) gives ~7% back under allocate-and-discard churn, which nets out to +2-4% on GC-heavy end-to-end workloads and less on anything that does real work between allocations. The multi-objspace machinery is gated behind a single-objspace check on hot paths. ### 4.5 Latency Beyond throughput, the qualitative change is who pauses: on master every GC of any Ractor stops all of them, so one allocation-heavy Ractor imposes its GC pauses on every other Ractor in the process. With per-Ractor GC a Ractor pauses only for its own collections; the remaining process-wide pauses are explicit `GC.start`, shareable-population growth and dead-Ractor cleanup, all of which are rare in steady state. ## 5. Limitations and future work * Incremental marking and non-stop-the-world compaction currently run only while the process has a single objspace. Per-objspace incremental marking is possible in principle (the machinery is per objspace already) but needs the single-to-multi transition handled mid-cycle. * `move:` uses an off-heap serialization; a zero-copy fast path (moving whole pages for large graphs) is future work, as is extending the FREEOBJ tracepoint beyond the main Ractor. * A global GC is still fully stop-the-world; making it concurrent or incremental is orthogonal future work. ## 6. Validation `make btest` (2054 tests) and `make test-all` are green on x86_64-linux across release, `RUBY_DEBUG=1`, ASAN, TSAN and MMTk builds. `GC.verify_internal_consistency` includes the containment verifier (`RGENGC_CHECK_MODE` builds run it around every collection); it was used throughout development. The branch adds ~90 Ractor/GC tests covering lifecycle, copy/move semantics, compaction interaction, and regressions for every bug found during a multi-week stress campaign (a corpus of ~1000 generated Ractor programs run under GC.stress, ASAN and TSAN). ## Notes * This work completes the design presented in [Toward Ractor local GC (RubyKaigi 2025)](https://rubykaigi.org/2025/presentations/ko1.html) * Much of this description, and a large part of the code, was written with Claude Code (Fable/Opus). * Acknowledgements * This work started as a collaboration with Rohit Menon. * Thanks to the Shopify Ractor team for their feedback. * And thank you, everyone, for waiting so long for this work. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:126187] [Ruby Bug#22216] Regexp backref and IO lastline are incompatible with Ractor
by headius (Charles Nutter) 07 Aug '26

07 Aug '26

Issue #22216 has been reported by headius (Charles Nutter). ---------------------------------------- Bug #22216: Regexp backref and IO lastline are incompatible with Ractor https://bugs.ruby-lang.org/issues/22216 * Author: headius (Charles Nutter) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Problem Several Regexp-matching methods currently write (and sometimes read) the implicit "backref" `$~` variable in the local frame (and related variables like `$'`). Several IO methods read or write the "last line" `$_` variable in the same way. In both cases, the result is a mutable object, which makes these variables already problematic for ractors. Making matters worse, the frame might be shared if a proc is captured and used across threads or ractors, and there's no static way to inspect a piece of code to know if it expects to read or write these variables. Where procs can be rejected by a proc for accessing captured state, there's no such check possible for these variables. All of these facts make the backref and lastline variables fundamentally incompatible with Ractor. ## Possible remedies A wholesale removal of these variables would solve the problem, but there's a lot of code that depends on them... much of that code without even realizing it, since they might not access the variables directly. In some cases, the dependencies are internal and part of the behavior of core methods. Hard errors when using methods that read or write these variables would avoid introducing threading problems into a Ractor, but would also break a large number of commonly-used methods. There have been experiments to make these variables both frame and thread-local, but they have never been made standard. Updates to backref and lastline are visible across threads and already can lead to concurrency issues even on CRuby. Deprecating the implicit behavior and making it opt-in (or opt-out?), perhaps with keyword arguments or file pragmas, might be a halfway measure. It would probably not be an easy transition. I don't know the right path forward, but I believe this issue needs to be discussed. ## JRuby perspective We continue to mimic CRuby behavior, which has led to our users occasionally running into issues when a proc accesses these variables across threads. Our recommendation: "don't do that". We also have had our frustrations optimizing around these variables, since they implicitly require access across calls. Because we cannot statically detect when they will be used, we essentially treat all method names that might *potentially* access them as deopt triggers. It's not ideal. I'd like to hear ideas for how to make these variables less "magic", less implicit and easier to deal with across calls (and across threads/ractors). -- https://bugs.ruby-lang.org/

6 19

[ruby-core:124714] [Ruby Bug#21870] Regexp: Warnings when using multiple non-overlapping \p{...} classes
by jneen (Jeanine Adkisson) 07 Aug '26

07 Aug '26

Issue #21870 has been reported by jneen (Jeanine Adkisson). ---------------------------------------- Bug #21870: Regexp: Warnings when using multiple non-overlapping \p{...} classes https://bugs.ruby-lang.org/issues/21870 * Author: jneen (Jeanine Adkisson) * Status: Open * ruby -v: 4.0.0, 4.0.1, earlier versions to a lesser extent * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ```ruby $VERBOSE = true # warning: character class has duplicated range: /[\p{Word}\p{S}]/ regex = /[\p{Word}\p{S}]/ ``` As far as I can tell this is a perfectly valid and non-overlapping set of unicode properties, but I am still being spammed with warnings. Using `/(\p{Word}|\p{S})/` is kind of a workaround, but it is slower. -- https://bugs.ruby-lang.org/

9 23