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

[ruby-core:126687] [Ruby Feature#22312] Add parent directory operations and recursive file removal
by nobu (Nobuyoshi Nakada) 07 Oct '26

07 Oct '26

Issue #22312 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Feature #22312: Add parent directory operations and recursive file removal https://bugs.ruby-lang.org/issues/22312 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I propose extending `Dir.mkdir`, `Dir.rmdir`, and `File.unlink` with options for operating on directory trees. These operations currently require `FileUtils`; providing them in core would also allow recursive removal to improve robustness by using native directory descriptors or Windows handles where available. ## Proposed API ````ruby Dir.mkdir(path, permissions = 0777, perm: permissions, parents: false) Dir.rmdir(path, parents: false, ignore_non_empty: false) File.unlink(*paths, recursive: false) ```` The aliases `Dir.delete`, `Dir.unlink`, and `File.delete` receive the corresponding options. Calls without the new options retain their existing behavior. ## Creating parent directories `Dir.mkdir(path, parents: true)` creates missing parent directories and returns `0` if the target is already a directory. An existing non-directory raises an exception. ````ruby Dir.mkdir("build/cache/objects", parents: true, perm: 0700) # => 0 ```` The requested permissions apply only to the final directory. New parents use `0777`, subject to the process umask, and existing directories keep their permissions. Permissions remain ignored on Windows. ## Removing empty parent directories `Dir.rmdir(path, parents: true)` removes the target and then successive empty parents. It does not remove a filesystem root or the relative parent path `.`. Its return value remains `0`. The `ignore_non_empty:` option controls when removal stops successfully: | Value | Target directory | Parent directories | |-------------------|--------------------------------|-----------------------------------------------------| | `false` (default) | Raise if non-empty | Raise if non-empty | | `true` | Stop successfully if non-empty | Stop successfully if non-empty | | `:parents` | Require successful removal | Stop successfully if non-empty or no longer present | Other errors raise exceptions. `:parents` matches the error handling of `FileUtils.rmdir(path, parents: true)` and has no effect without `parents: true`. Removal already completed is not rolled back on an error. ````ruby Dir.rmdir("build/cache/objects", parents: true, ignore_non_empty: :parents) ```` Parent removal currently uses path-based calls to `rmdir`, resolving the path again at each step. It does not guarantee protection against concurrent renames or symbolic-link substitution in intermediate path components. Such changes can redirect removal to unintended empty directories that the process has permission to remove. Avoid using this option where another process can modify the path concurrently. Retaining descriptors for all ancestors would require a number of descriptors proportional to the path depth. Walking upward with `openat(fd, "..")` would bound descriptor usage, but could follow a directory into a different parent after a concurrent rename. The current proposal retains path-based parent removal with the limitation described above. ## Recursive removal `File.unlink(*paths, recursive: true)` also removes directories and their contents. It returns the number of supplied paths, rather than the number of entries removed. ````ruby File.unlink("build/cache", recursive: true) # => 1 ```` Symbolic links at the target, including targets specified with trailing slashes, and links inside the tree are removed without traversing their targets in the absence of concurrent replacement. Filesystem roots and paths ending in `.` or `..` are rejected. Like `FileUtils.rm_r` with its default `force: false`, this option does not suppress errors: missing paths and other failures raise exceptions, possibly after partial removal. The implementation uses descriptor-relative operations, including `openat` and `unlinkat`, on platforms supporting them. Opened directories remain accessible through their descriptors if renamed during traversal, so their contents may still be removed after a rename. Concurrent modifications can cause an exception; the operation is not atomic. Mounted filesystems inside the tree are traversed on non-Windows platforms. On Windows, the implementation retains directory handles with sharing disabled and removes entries through their handles. Reparse points in the ancestor path are rejected; reparse points at or inside the target are removed without traversal. Existing handles that conflict with exclusive access cause an error. On other platforms, a path-based fallback behaves similarly to `FileUtils.remove_entry`. It cannot prevent traversal through a symbolic link substituted concurrently for a directory, so it is unsuitable for trees another process can modify concurrently. ## Possible `force:` option An additional `force: false` keyword for `File.unlink` may be useful for cleanup operations. Combined with `recursive: true`, it could cover use cases currently served by `FileUtils.rm_rf`. This option is not implemented in the current patch. The scope of error suppression needs discussion: should `force: true` ignore only missing paths, or suppress removal errors more broadly as `FileUtils.rm_r(force: true)` does? Its applicability without `recursive: true` and the return value when some supplied paths cannot be removed also need to be defined. ## Implementation [Implementation branch](https://github.com/nobu/ruby/tree/recursive-file-operations) -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126756] [Ruby Bug#22328] Should IO#wait_priority be deprecated and then removed?
by sampokuokkanen (Sampo Kuokkanen) 07 Oct '26

07 Oct '26

Issue #22328 has been reported by sampokuokkanen (Sampo Kuokkanen). ---------------------------------------- Bug #22328: Should IO#wait_priority be deprecated and then removed? https://bugs.ruby-lang.org/issues/22328 * Author: sampokuokkanen (Sampo Kuokkanen) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- In #18655, IO#wait_readable, IO#wait_writable, IO#wait_priority, and IO#wait were moved from io/wait into core. However, in #18655 note 11, Matz wrote: > After the discussion, we will drop wait_priority, but others are accepted. https://bugs.ruby-lang.org/issues/18655#note-11 https://github.com/ruby/dev-meeting-log/blob/d16be491afb7f3c0d956a6445dcb17… IO#wait_priority is still present in core today. It does not seem to be used that much: https://github.com/search?type=code&q=.wait_priority+language%3ARuby&l=Ruby So my question is, should it be deprecated and removed? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:126967] [Ruby Feature#11817] map.parallel
by matz (Yukihiro Matsumoto) 07 Oct '26

07 Oct '26

Issue #11817 has been updated by matz (Yukihiro Matsumoto). Status changed from Open to Closed Thank you for bringing a concrete use case. For I/O-bound work like yours, this already works today: ```ruby results = items.map { |item| Thread.new { process(item) } }.map(&:value) ``` Beyond that, a built-in method has to decide the things @rkh listed: which execution unit to use, how many run at once, and what happens to the others when one fails. I don't see a single answer that fits everyone, so for now I think this belongs to gems such as `async`, `concurrent-ruby` or `parallel`. Matz. ---------------------------------------- Feature #11817: map.parallel https://bugs.ruby-lang.org/issues/11817#change-119364 * Author: eike.rb (Eike Dierks) * Status: Closed ---------------------------------------- I'd like to suggest a new method: #parallel That method should take care of executing workloads in parallel across multiple cores. I believe that #map can sometimes be distributed to many simultaneous threads. So we would spread out the map blocks into parallel processing, and then collect the results in order. I believe this would need some new infrastructure like apple did with great_central, so I'm talking along these lines. (Aka we only want to open up as many threads as there are cores) This would not help much with a simple map (because we need to collect and serialize the results in the end) but it could be cool for more complex mappings. Maybe this should have been a rails topic first, because there it might make a lot of sense to render partials in parallel, this could really speed up rails response rendering ;-) But I believe this is a topic for ruby in general. Given that we now go to really many cores, it should be at the heart of ruby to use that. For a start we could just declare #parallel as -> return self. and than improve on it. A naive implementation would just open a new thread for every parallel map block, but that would not work well -- it actually would be very slow. So we actually need a thread management, along the lines of great central. I believe this should be built into the very core libs of the ruby language. I know this is hard stuff, but it needs to be done. Let's go parallel from the heart of the language. --- Please let us discuss if adding the #parallel method would be a good idea. Let's come up with some implementations to find the problems. I'm explicitly referring to map#parallel here. In rails that might be cache.parallel (if you followed) for some math tasks it might also be parallel do {} -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126832] [Ruby Feature#22376] Undefine the allocator for Class
by jhawthorn (John Hawthorn) 07 Oct '26

07 Oct '26

Issue #22376 has been reported by jhawthorn (John Hawthorn). ---------------------------------------- Feature #22376: Undefine the allocator for Class https://bugs.ruby-lang.org/issues/22376 * Author: jhawthorn (John Hawthorn) * Status: Open ---------------------------------------- Uninitialized classes, created by `Class.allocate`, are a recurring source of bugs (most recently #22341). Every place that inspects a class's superclass chain has to check whether the class has been initialized, and it's easy to forget one. I'd like to propose that we forbid Class.allocate, as we already do for several other core types (Proc, Method, UnboundMethod, Binding). To do this we: * Undefine the allocator for Class (`rb_undef_alloc_func`) * Replace `Class#initialize` with a Class.new singleton method that allocates and initializes in one step. * Define `Class#dup` and `Class#clone` so that copying a class still works `Class` can't be subclassed, so I don't think we need to worry about calling initialize. The only place I found `Class.allocate` via `gem-codesearch` were copies of ruby/spec, so I don't think forbidding that will cause problems. Before: ```ruby klass = Class.allocate Class.new(klass) # 'Class#initialize': can't inherit uninitialized class (TypeError) klass.superclass # 'Class#superclass': uninitialized class (TypeError) ``` After: ```ruby Class.allocate # undefined method 'allocate' for class Class (NoMethodError) Class.instance_method(:allocate).bind_call(Class) # 'Class#allocate': allocator undefined for Class (TypeError) ``` PR: https://github.com/ruby/ruby/pull/18964 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:126956] [Ruby Feature#18439] YJIT: Support Microsoft x86 calling convention
by hsbt (Hiroshi SHIBATA) 07 Oct '26

07 Oct '26

Issue #18439 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Assigned to Closed Assignee changed from jit to hsbt (Hiroshi SHIBATA) https://github.com/ruby/ruby/pull/19114 has been merged. I will start by testing YJIT on the mswin platform, using it in my daily work. For mingw, I will consider support in Ruby 4.2 or later, after confirming that no problems occur. ---------------------------------------- Feature #18439: YJIT: Support Microsoft x86 calling convention https://bugs.ruby-lang.org/issues/18439#change-119351 * Author: usa (Usaku NAKAMURA) * Status: Closed * Assignee: hsbt (Hiroshi SHIBATA) ---------------------------------------- I heard that supporting YJIT for VC++ needs mmap from k0kubun-san, so I implemented tiny mmap emulation on Windows and committed it to master. And, I found we need more changes to actually enabled YJIT for VC++, at least: - YJIT requires `OPT_DIRECT_THREADED_CODE` or `OPT_CALL_THREADED_CODE` in `rb_yjit_compile_iseq()`. Really? - Maybe ABI deffers between VC++ and YJIT's expectation. Can I get support to fix above? -- https://bugs.ruby-lang.org/

1 0

[ruby-core:125877] [Ruby Feature#22134] Faster rb_scan_args() for keyword args (optimization)
by luke-gru (Luke Gruber) 07 Oct '26

07 Oct '26

Issue #22134 has been reported by luke-gru (Luke Gruber). ---------------------------------------- Feature #22134: Faster rb_scan_args() for keyword args (optimization) https://bugs.ruby-lang.org/issues/22134 * Author: luke-gru (Luke Gruber) * Status: Open ---------------------------------------- ## Motivation When using the `rb_scan_args()` API, often we want to find a value for a given keyword argument. In order to do this, we call `rb_scan_args()` like so: ```c VALUE str; VALUE kwargs; VALUE example; rb_scan_args(argc, argv, "1:", &str, &kwargs); // duplicates the kwargs hash in argv if (!NIL_P(kwargs)) rb_get_kwargs(kwargs, &id_example, 0, 1, &example); // mutates the duplicated kwargs hash to retrieve `example:` ``` This duplicates the keyword args hash given in `argv`. It would be nice to be able to grab a direct reference to the keyword hash and to have a variant of `rb_get_kwargs()` that didn't mutate the passed in hash. ## Proposal Add a new valid format character for `rb_scan_args()`: ```c VALUE str; VALUE kwargs; VALUE example; rb_scan_args(argc, argv, "1:^", &str, &kwargs); // access kwargs directly from argv if (!NIL_P(kwargs)) rb_get_kwargs_const(kwargs, &id_example, 0, 1, &example); // don't mutate the passed kwargs hash ``` This '^' character would only be valid after a ":'. I have a [pull request](https://github.com/ruby/ruby/pull/17558) available for anyone that is interested. Thank you! -- https://bugs.ruby-lang.org/

3 5

[ruby-core:126598] [Ruby Feature#22300] `Ractor.check_isolation`: report Ractor isolation violations as warnings instead of raising
by ufuk (Ufuk Kayserilioglu) 07 Oct '26

07 Oct '26

Issue #22300 has been reported by ufuk (Ufuk Kayserilioglu). ---------------------------------------- Feature #22300: `Ractor.check_isolation`: report Ractor isolation violations as warnings instead of raising https://bugs.ruby-lang.org/issues/22300 * Author: ufuk (Ufuk Kayserilioglu) * Status: Open * Target version: 4.1 ---------------------------------------- ## Summary We are proposing a `Ractor.check_isolation { ... }` method which runs the given block in a special non-main Ractor. Inside that Ractor, supported operations that would fail because of Ractor isolation report a `:ractor_isolation` category warning, and then continue, instead of raising an isolation error. The special Ractor that is used to run the `Ractor.check_isolation` block is a real non-main Ractor. For example, `Ractor.main?` returns `false` and `Ractor.current` returns a genuine Ractor with its own default port. This is possible by ensuring that no other Ractor executes Ruby concurrently with this special Ractor. That exclusivity makes the "warn and continue" contract safe. ### Examples A trivial code example: ```ruby class Config @settings = {} # not shareable @values = [] # also not shareable def self.settings = @settings def self.values = @values end # Today: the first violation ends the run. Ractor.new { Config.settings }.value #=> Ractor::RemoteError # whose cause is Ractor::IsolationError: can not # get unshareable values from instance variables of # classes/modules from non-main Ractors # With `check_isolation`: the violation is a warning, and the run continues. Ractor.check_isolation do Config.settings # warning, not exception Config.values # ...and the next one is also reported Ractor.main? #=> false end ``` The next example is a test suite that can collect the supported isolation violations in a single run: ```ruby # test_helper.rb ISOLATION_WARNINGS = Thread::Queue.new Warning.singleton_class.prepend(Module.new do def warn(msg, category: nil) if category == :ractor_isolation && !Thread.current[:capturing_isolation_warning] Thread.current[:capturing_isolation_warning] = true begin ISOLATION_WARNINGS << Ractor.make_shareable(msg) ensure Thread.current[:capturing_isolation_warning] = false end return end super end end) class ActiveSupport::TestCase def run(...) Ractor.check_isolation { super } end end ``` ## 1. Motivation ### 1.1 An isolation error stops the run at the first violation Migrating a large codebase to Ractor-safety is difficult, since running it inside a real Ractor gives only one violation per run, which needs to be made Ractor-safe before you can observe the next violation. A large codebase has thousands, if not tens of thousands of these Ractor isolation violations that need to be identified. Our team at Shopify started an effort to make Rails Ractor-safe earlier this year, and as part of that work we needed the full list of isolation problems and not just the first item. To tackle this problem, we used an agent assisted loop against a scaffolded Rails application which served 165 endpoints inside a Ractor. We directed the agent loop to identify and fix the source of the `Ractor::IsolationError`, and run the loop again, until all endpoints could successfully run. While this approach did end up getting us a list of isolation violations, it proved to be an cumbersome task even with agent assistance. Instead, when we built the original prototype of `Ractor.check_isolation`, our initial run reported 50,995 warnings, of which 353 were unique in a matter of minutes with no agent assistance at all. A later run against Rails `main` reported 58,315 warnings, of which 419 were unique. The same work needs 419 build/fix/rebuild cycles (performed by agents or humans) to collect the same information. ### 1.2 You cannot put an existing test suite inside a real Ractor The obvious alternative to the above is to put a `Ractor.new { ... }` around each test in the test suite of the codebase. This approach, while attractive, does not work on real codebases, for three main reasons: 1. The test code must itself be Ractor-safe. Making the tests safe is often harder than making the application safe. Most test helpers hold mutable global state on purpose. 2. The block of `Ractor.new` must be isolated. It cannot close over the test case, the fixtures or the assertion state. 3. Non-shareable arguments and return values are copied. However, copying is not possible for some objects, for example a `Proc`, and the run aborts. `Ractor.check_isolation` removes all three obstacles. The block is not isolated. Arguments, the return value and outgoing message payloads pass by reference. Moreover, any isolation violation warning reported from the test file sources can easily be discarded as irrelevant. ### 1.3 There is no way to keep a codebase Ractor-safe Given the above point, this is the argument that matters most in the long term, in our opinion. A codebase that is Ractor-safe today will not stay Ractor-safe in the future. As the codebase evolves, one new lazy memoization, or one new unfrozen constant in a dependency, will reintroduce a violation. A normal test suite cannot detect the change, because the test suite does not run in a Ractor (as explain in the previous point). A gem can therefore break its downstream users without any signal, and the failure would only appear in production. `Ractor.check_isolation` turns Ractor safety into a property that CI can measure. A gem or an application can wrap its tests in the block and fails the build when the count of unique warnings increases. In essence, our argument is that this proposal gives the ecosystem two things it does not have today: - a burn-down list, to make a codebase Ractor-safe; - a ratchet, to keep it Ractor-safe. ## 2. Proposal ```ruby Ractor.check_isolation(*args, name: nil) { |*args| ... } # -> the value of the block ``` `Ractor.check_isolation` method: - runs the block in a new, real, and special non-main Ractor; - does not isolate the block, and passes arguments by reference; - reports each supported isolation violation as a `:ractor_isolation` category warning, and continues without raising; - unlike an ordinary Ractor, returns a non-shareable block value without copying it, preserving object identity. The reported violations match the constructs that would have raised a `Ractor::IsolationError` under a normal non-main `Ractor`. They include, but are not limited to: - instance variables and class variables of classes and modules; - constants that hold non-shareable objects; - global variables; - `Ractor.make_shareable`, `Ractor.shareable_proc` and `Ractor.shareable_lambda` failures; - calls to Ractor-unsafe C methods; - `fork` from a non-main Ractor; - defining or undefining finalizers on objects owned by another Ractor; - a call to a method that `define_method` defined with a non-shareable `Proc`; - isolation of the check block when it captures outer variables or uses `yield`. The user suppresses isolation-violation warnings with `Warning[:ractor_isolation] = false` or with `-W:no-ractor_isolation`. The exclusivity of the special Ractor that run the block is a precondition of the method, not a mode that the user should select. The current patch relies on `RUBY_RACTOR_EXCLUSIVE=1` and warns when it is unavailable. However, for the final solution we propose that `Ractor.check_isolation` instead establish exclusivity itself and raise when it cannot. Section 4.3 discusses the implementation constraints regarding this. The exclusive mode mentioned here is not a stop-the-world barrier. A blocking operation still hands the run slot over, so that, for example, work that the block correctly dispatches to the main Ractor completes, and the program does not deadlock. ## 3. Implementation Our current patch is on this branch: https://github.com/Shopify/ruby/compare/master...Shopify:ruby:ractor-check-… The branch exposes the design described here under the name `Ractor.check_isolation`. Main points: - A new warning category, `RB_WARN_CATEGORY_RACTOR_ISOLATION`, registered as `:ractor_isolation`. - A flag on the special `rb_ractor_t`. A helper, `rb_ractor_isolation_violation()`, replaces the raise at many of the covered violation sites. The helper warns when the current Ractor has the flag set, and raises otherwise. - `ractor_create0()` creates and marks the special Ractor. When `rb_thread_create_ractor()` starts it, `thread_create_core()` skips `rb_proc_isolate_bang()` and retains the argument array by reference. `rb_proc_check_isolation_warn()` reports the `Proc`-isolation violations that `Ractor.new` would raise, and leaves the closure intact. - `ractor_prepare_payload()` passes a non-shareable message payload by reference, with a warning, instead of copying it. - The bmethod call paths warn instead of raising for a cross-Ractor call to a method defined with a non-shareable `Proc`. - On builds with M:N scheduling, `ruby_mn_threads_params()` enables it and sets `max_cpu = 1` under `RUBY_RACTOR_EXCLUSIVE=1`. - The first call switches the VM into multi-ractor mode. This switch is one-way today. Two costs with the current patch are worth stating explicitly: 1. The VM keeps the multi-ractor overhead for the rest of the process, and 2. the checks sit on paths that a production process executes. We consider these costs acceptable since this feature is a development and CI tool, and should not be enabled in production mode. ## 4. Open questions We have used this feature for four months on Rails and on two large production applications at Shopify. The following questions come out of that use. We do not have a strong position on most of them. 1. **Is `warn` the right surface?**: `Warning.warn` was the cheapest thing to build, but it may be the weakest part of the design, for the following reasons: - The volume is high. In one Shopify application, the run produced more warning text than the 6 GB memory limit of the CI worker, so it was killed. The consumers want a deduplication by site, not a stream of strings. - A string throws the structure away. The consumers want the class, the variable name, the reference chain and the location as data, rather than parsing whatever information is available from the message. - Re-entrancy is a real hazard. Any code in the handler can itself trigger a violation. We hit an infinite recursion this way, and we also hit a stack overflow because formatting the message called `to_s` on a proxy module. - `Warning.warn` is global process state. A warning that the special Ractor reports is awkward to collect in the caller. The alternatives are a callback, or a reporter object: ```ruby Ractor.check_isolation(on_violation: ->(violation) { ... }) { ... } Ractor.check_isolation(reporter: MyReporter.new) { ... } ``` A `violation` object can carry the class, the name, the kind, the reference chain and the backtrace. The warning category can stay as the default when the caller gives no callback. 2. **Should the checks be a build-time option?** The checks add work to hot paths. An alternative is to compile them only into a build that configures them, in the same way as `RGENGC_CHECK_MODE`. This trades convenience for speed. We do not know which side upstream prefers, but considering that so few Ruby developers know how to build a special version of Ruby, we think this will stop the widespread adoption of the feature. 3. **How does the method establish exclusivity?** The current patch reads a boot flag, `RUBY_RACTOR_EXCLUSIVE=1`, and warns once when the flag is absent. We do not propose that as the interface for the final state. The constraint for why we have the boot flag is technical and we welcome suggestions to removing it. Two mechanisms in `thread_sched.c` decide the outcome: - `vm->ractor.sched.max_cpu` caps the number of shared native threads. The VM reads it when an NT rejoins the pool, so lowering it at runtime does not retire the NTs that already exist. They retire lazily, and `SNT_KEEP_MINIMUM` keeps some of them alive. - `enable_mn_threads` decides how each thread gets a native thread, and the VM reads it when the thread is created. A thread created while the flag was off holds a dedicated native thread. A dedicated NT is its own OS thread and ignores `max_cpu` completely. Together these mean that a switch at the time of the call cannot cover the threads that the process already has, but it can cover a process with no other living threads. We therefore propose: - `Ractor.check_isolation` switches the VM to a single run slot when it is the only living thread in the process, and runs the block; - otherwise it raises, and names the threads that prevent the guarantee. This removes the flag from the common case, and it turns a silent unsound result into an error. Ideally, we would like to find a solution where we can create a special exclusive Ractor regardless of the state of the VM, but need more guidance on how to achieve that. 4. **How does this interact with Feature #22226?** Class and module ownership changes which accesses are violations. The checker must follow the same rule, and we are prepared to improve the proposal to obey this invariant as well. Moreove, the special Ractor should also behave like how a real Ractor would with respect to the ownership of the classes/modules that the block creates. Otherwise, it would report fewer violations than a production worker would hit. 5. **Is passing by reference acceptable in a public API?** The block, the arguments, the return value and outgoing message payloads all bypass the isolation rules. This is sound because the special Ractor runs exclusively, so it is not a safety concern. 6. **What are the semantics for nested calls and for threads?** In our current patch, a nested call creates another special Ractor and resumes the calling Ractor when it returns. A thread that the block creates belongs to the special Ractor and therefore observes the check and only raises warnings. On the other hand, a Ractor created with `Ractor.new` does not inherit the check, and raises `Ractor::IsolationError` for isolation errors. We think this behaviour is right, but it should be specified. 7. **Should the VM deduplicate?** Most consumers want unique violations per source location, and they build that themselves. A `Set` of sites in the VM would cut the volume by two orders of magnitude. On the other hand, it might also hide a violation that occurs on a second path through the same line, and would make it hard to collect how many times each unique violation is seen. ## 5. Related issues - #22226: Ractor: class/module ownership. Changes which accesses are violations. - #22252: improve the "defined with an un-shareable Proc in a different Ractor" error. This feature downgrades the same check to a warning. - [ruby/ruby#15983](https://github.com/ruby/ruby/pull/15983): the reference chain in `Ractor::IsolationError#detailed_message`. Adding the same chain to the warnings would make a violation more actionable. ## 6. Acknowledgements Different parts of this patch were built by Ufuk Kayserilioglu, Edouard Chin and Hartley McGuire, using LLM assistance. @ko1 provided guidance on our original approach which was using a special Thread instead of a special Ractor. -- https://bugs.ruby-lang.org/

3 2

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

07 Oct '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/

2 1

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

06 Oct '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/

5 4

[ruby-core:126933] [Ruby Feature#11817] map.parallel
by rkh (Konstantin Haase) 06 Oct '26

06 Oct '26

Issue #11817 has been updated by rkh (Konstantin Haase). > Nearly 11 years after this issue was opened, has Ruby’s concurrency model evolved enough that something like this could now be reconsidered? Would you expect the blocks to run in Threads, Fibers, or Ractors? A fixed or dynamic pool of Threads or Ractors? How is that managed? Or a true system thread for each value? How are exceptions being dealt with? For the Ractors, should the collection values be copied or moved? For Fibers, how would this be handled if no scheduler is set up (Ruby doesn't ship with a built-in one)? I do think such functionality is either done explicitly (using `Thread.new { ... }.value`, `Ractor.new(it) { ... }.value`, or `Fiber.schedule { ... }`) or provided by one of the concurrency gems (`async` or `concurrent-ruby`), which come with built-in thread pools. ---------------------------------------- Feature #11817: map.parallel https://bugs.ruby-lang.org/issues/11817#change-119325 * Author: eike.rb (Eike Dierks) * Status: Open ---------------------------------------- I'd like to suggest a new method: #parallel That method should take care of executing workloads in parallel across multiple cores. I believe that #map can sometimes be distributed to many simultaneous threads. So we would spread out the map blocks into parallel processing, and then collect the results in order. I believe this would need some new infrastructure like apple did with great_central, so I'm talking along these lines. (Aka we only want to open up as many threads as there are cores) This would not help much with a simple map (because we need to collect and serialize the results in the end) but it could be cool for more complex mappings. Maybe this should have been a rails topic first, because there it might make a lot of sense to render partials in parallel, this could really speed up rails response rendering ;-) But I believe this is a topic for ruby in general. Given that we now go to really many cores, it should be at the heart of ruby to use that. For a start we could just declare #parallel as -> return self. and than improve on it. A naive implementation would just open a new thread for every parallel map block, but that would not work well -- it actually would be very slow. So we actually need a thread management, along the lines of great central. I believe this should be built into the very core libs of the ruby language. I know this is hard stuff, but it needs to be done. Let's go parallel from the heart of the language. --- Please let us discuss if adding the #parallel method would be a good idea. Let's come up with some implementations to find the problems. I'm explicitly referring to map#parallel here. In rails that might be cache.parallel (if you followed) for some math tasks it might also be parallel do {} -- https://bugs.ruby-lang.org/

1 0