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

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

15 Mar '26

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

2 6

[ruby-core:124634] [Ruby Feature#21852] New improved allocator function interface
by byroot (Jean Boussier) 15 Mar '26

15 Mar '26

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

2 8

[ruby-core:125003] [Ruby Feature#21953] Allow accessing unshareable objects within a Ractor-local Ruby Box
by tikkss (Tsutomu Katsube) 15 Mar '26

15 Mar '26

Issue #21953 has been reported by tikkss (Tsutomu Katsube). ---------------------------------------- Feature #21953: Allow accessing unshareable objects within a Ractor-local Ruby Box https://bugs.ruby-lang.org/issues/21953 * Author: tikkss (Tsutomu Katsube) * Status: Open ---------------------------------------- ### Status Currently, non-main ractors prohibit access to the following objects to prevent data races: * Global variables * Class variables * Unshareable class instance variables * Unshareable constants ### Proposal I would like to propose that allow reading/writing unshareable objects inside a Ruby Box created in a non-main ractor: ```ruby # lib/x.rb class X # can write unshareable objects XXX = "1" @@cvar = "1" @ivar = "1" class << self def cvar; @@cvar; end def ivar; @ivar; end end end # can read unshareable objects $LOAD_PATH # => returns $LOAD_PATH includes lib directory X.cvar # => "1" X.ivar # => "1" X::XXX # => "1" # main.rb Ractor.new do local_box = Ruby::Box.new local_box.eval <<~RUBY base_dir = File.expand_path(File.dirname(__FILE__)) lib_dir = File.join(base_dir, "lib") # can write unshareable objects $LOAD_PATH.unshift(lib_dir) RUBY local_box.require("x") x = local_box::X.new end.join ``` Ruby Box can isolate global/class variables, class/module definitions from other boxes. A Ruby Box created inside a non-main ractor cannot be accessed from other ractor. If that is the case, wouldn’t it be fine to access unshareable objects inside that box? So I would like to propose that allow reading/writing unshareable objects inside a Ruby Box created in a non-main ractor. ### Background We are working on implementing a Ractor based parallel test runner for the test-unit gem. Ractor is a great for parallel processing. However, many existing libraries still rely on class variables or class instance variables for configuration. Ideally, we should reduce the use of class variables or class instance variables. Currently, we tried fixing several non-shareable objects, but we could not resolve all of them yet. We will continue working on this issue, but we are also exploring other approaches. This is the idea begind this proposal. I think the work needed to make objects shareable when running exisiting libraries with Ractor can be reduced. ### FAQ Q: Can we create a Ruby Box inside a non-main ractor? A: Yes: ```ruby Ractor.new {Ruby::Box.new}.join ``` Q: Is a Ruby Box created in a non-main ractor truly inaccessible from other ractor? A: No. I'm not sure if it's intentional, but a Ruby Box is a shareable object. Also, it can be accessed from the main Ractor by using `Ractor#value`: ```ruby Ractor.shareable?(Ruby::Box.new) # => true ``` ```ruby Ractor.new {Ruby::Box.new}.value # => #<Ruby::Box:3,user,optional> ``` To implement this proposal, Ruby Box may need to be an unshareable object, and passing it with `Ractor#value` may need to be disallowed. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124808] [Ruby Misc#21877] DevMeeting-2026-03-17
by mame (Yusuke Endoh) 15 Mar '26

15 Mar '26

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

7 6

[ruby-core:116589] [Ruby master Misc#20238] Use prism for mk_builtin_loader.rb
by kddnewton (Kevin Newton) 13 Mar '26

13 Mar '26

Issue #20238 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20238: Use prism for mk_builtin_loader.rb https://bugs.ruby-lang.org/issues/20238 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- I would like to propose that we use prism for mk_builtin_loader.rb. Right now the Ruby syntax that you can use in builtin classes is restricted to the base Ruby version (2.7). This means you can't use a lot of the nicer syntax that Ruby has shipped in the last couple of years. If we switch to using prism to parse the builtin files instead of using ripper, then we can always use the latest version of Ruby syntax. A pull request for this is here: https://github.com/kddnewton/ruby/pull/65. The approach for the PR is taken from how RJIT bindgen works. -- https://bugs.ruby-lang.org/

6 22

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

13 Mar '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/

7 17

[ruby-core:124918] [Ruby Bug#21940] Ruby::Box: `$_` returns stale value due to gvar_tbl caching
by dak2 (Daichi Kamiyama) 12 Mar '26

12 Mar '26

Issue #21940 has been reported by dak2 (Daichi Kamiyama). ---------------------------------------- Bug #21940: Ruby::Box: `$_` returns stale value due to gvar_tbl caching https://bugs.ruby-lang.org/issues/21940 * Author: dak2 (Daichi Kamiyama) * Status: Open * ruby -v: 4.0.1 * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Environment - Ruby Version v4.0.1 - OS: macOS 15.6.1 (arm64) - `RUBY_BOX=1` enabled ## Reproduction ```shell echo -e "a\nb" | RUBY_BOX=1 ruby -e 'gets; $_; gets; p $_' ``` ## Expected ``` "b\n" ``` The second gets reads `"b"` and sets it to `$_`. `p $_` should return the latest value. ## Actual ``` "a\n" ``` `$_` returns the stale value from the first gets. ## Root Cause `$_` is a special variable stored in `svar`. Its getter (`rb_lastline_get`) reads the current value from svar each time it is called. However, when Box is enabled, I believe `rb_gvar_get()` caches the value in the Box's `gvar_tbl` on first access. On subsequent reads, it returns the cached value directly without calling the getter. Since gets updates `$_` via `rb_lastline_set()` which bypasses `rb_gvar_set()`, the cache becomes stale. -- https://bugs.ruby-lang.org/

2 2

[ruby-core:124971] [Ruby Feature#21950] Add a built-in CPU-time profiler
by osyoyu (Daisuke Aritomo) 12 Mar '26

12 Mar '26

Issue #21950 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Feature #21950: Add a built-in CPU-time profiler https://bugs.ruby-lang.org/issues/21950 * Author: osyoyu (Daisuke Aritomo) * Status: Open ---------------------------------------- Modern CRuby workloads can consume CPU concurrently across multiple native threads, especially with multiple Ractors and C exts which release the GVL. I'd like to propose the idea of integrating a built-in CPU-time profiler CRuby to enable more accurate and stable profiling in such situations. ## Motivation & Background CPU profilers indicate how much CPU time were consumed by different methods. Most CPU-time profilers rely on the kernel to track consumed CPU time. `setitimer(3)` and `timer_create(3)` are APIs to configure kernel timers. The process receives a profiling signal (SIGPROF) every given time of CPU time consumed (e.g. 10 ms). In general, a profiler needs to know which _thread_ consumed how much CPU time to attribute work to the correct thread. This wasn't a real requirement for Ruby in the pre-Ractor age, since only one native thread could consume CPU time at any given moment due to GVL limitations. Using process-wide CPU-time timers provided by `setitimer()` effectively did the job. It was safe to assume that the active thread was doing some work using the CPU when a profiling signal arrived. Of course, this assumption does not stand in all situations. One is the case where C extensions release the GVL. Another is the multi-Ractor situation. In these cases, multiple native threads may simultaneously consume CPU time. Linux 2.6.12+ provides a per-thread timer to address this task. Profilers such as [Pf2](https://github.com/osyoyu/pf2) and [dd-trace-rb](https://github.com/DataDog/dd-trace-rb) use this feature to keep track of CPU time. However, utilizing this API requires information that CRuby does not necessarily expose. Both carry copies of CRuby headers in order to access internal structs such as `rb_thread_t`. This is quite fragile and possibly unsustainable in the age where CRuby evolves towards Ractors and M:N threading. ## Proposal Implement a built-in CPU-time profiler as `ext/profile`, and add some information extraction points to the VM built exclusively for it. ```ruby require 'profile' RubyVM::Profile.start # your code here RubyVM::Profile.stop #=> results ``` `ext/profile` will take care of the following in coordination with some VM helpers: - Tracking creation and destruction of native thread (NT) s - Management of kernel timers for those threads - i.e. calling `pthread_getcpuclockid(3)` and `timer_create(3)` - This will require iterating over all Ractors and shared NTs on profiler init - Handling of SIGPROF signals which those timers will generate - Walking the stack (calling `rb_profile_frames()`) - I'm not going to make this part of this ticket, but I'm thinking we can make `rb_profile_frames()` even more granular by following VM instructions, which is probably something we don't want to expose as an API We would need to add some APIs to the VM for `ext/profile`: - An API returning all alive NTs - Event hooks notifying creation and destruction of NTs - Event hooks notifying assign/unassign of RTs to NTs Since only Linux provides the full set of required kernel features, the initial implementation will be limited to Linux systems. I can expand support to other POSIX systems by employing `setitimer()` later, but they will receive limited granularity (process-level CPU-time timers). ### Output interface One thing to consider is the output format. I think we have a few practical choices here: - Adopt pprof's `profile.proto` format. - This is a widely accepted format across tools including visualizers. - The format itself is pretty flexible, so it shouldn't be hard to add custom fields. - Just return a Hash containing profile results. - We'd need to design some good format. ### Things out of scope - Visualization - Interaction with external visualizers / trackers / etc These can be better left to normal RubyGems. ### Why not an external gem? Through maintaining [Pf2](https://github.com/osyoyu/pf2), an CPU-time profiler library, I have encountered many difficulties obtaining information required for accurate profiling. The rule of thumb is that more internal information a profiler can access, the more accuracy it can achieve. However, from the CRuby maintenance perspective, I suppose not too many APIs exposing implementation details are wanted. Locating a profiler under `ext/` looks like nice middle ground. Placing core 'profiling' logic (sampler scheduling, sampling itself) in CRuby and abstracting it as 'RubyVM::Profile' should work cleanly. It should be noted that existing profilers have their own unique features, such as markers, unwinding of C stacks and integration with external APMs. I don't want to make this a tradeoff between accuracy and feature; instead, I'd like to design an API where both could live. ### Study on other languages A handful of VM-based languages carry profiler implementation in their runtime. - Go: runtime/pprof https://github.com/golang/go/tree/master/src/runtime/pprof - OpenJDK: JFR https://github.com/openjdk/jdk/tree/master/src/hotspot/share/jfr - Node.js: --cpu-prof https://nodejs.org/en/learn/getting-started/profiling - And more Among these, OpenJDK is a notable entry. JVM profilers have configured used `AsyncGetCallTrace()`, which is just like `rb_profile_frames()`, to obtain stack traces from signal handlers. The signal originates from kernel timers installed by the profilers, configured to fire every specified interval of CPU time (e.g. 10 ms). Even though `AsyncGetCallTrace()` and async-profiler (its primary user) are very sophisticated and battle-tested, JFR folks have decided to control sampling timing within the runtime to improve accuracy and stability. For more information on JVM, see: - [JEP 509](https://openjdk.org/jeps/509) - [JEP 518](https://openjdk.org/jeps/518) - [Taming the Bias: Unbiased* Safepoint-Based Stack Walking in JFR](https://mostlynerdless.de/blog/2025/05/20/taming-the-bias-unbiased-safepoint-based-stack-walking-in-jfr/) -- https://bugs.ruby-lang.org/

5 15

[ruby-core:123871] [Ruby Feature#21700] `IO::Buffer.map`: offset argument is "broken" and needs to be made more useful
by trinistr (Alexander Bulancov) 12 Mar '26

12 Mar '26

Issue #21700 has been reported by trinistr (Alexander Bulancov). ---------------------------------------- Feature #21700: `IO::Buffer.map`: offset argument is "broken" and needs to be made more useful https://bugs.ruby-lang.org/issues/21700 * Author: trinistr (Alexander Bulancov) * Status: Open ---------------------------------------- *This was supposed to be a bug report, but it turned into a feature request halfway through.* `IO::Buffer.map` supports `size` and `offset` arguments to localize buffer to a specific part of mapped file. While `size` works fine, specifying `offset` as anything but 0 is a recipe for disaster. 1. It is practically undocumented. This is it currently: "Optional size and offset of mapping can be specified." While `size` can be whatever user desires, `offset` can only be set to specific values. It was *very* surprising when I started testing it, as I expected it to behave similar to size and offset of a slice. Which values are allowed? That's the next point. 2. Possible values for `offset` are highly platform-dependent. - On Linux it must be a multiple of page size. (https://www.man7.org/linux/man-pages/man2/mmap.2.html) - On macOS it can be any value? manpage doesn't specify exactly. (https://developer.apple.com/library/archive/documentation/System/Conceptual… (I looked at the manpage on a mac, seems to be the same.)) - On Windows it must be a multiple of some value that *isn't* page size and page size doesn't work here. StackOverflow says it's 64 kB, but that didn't work for me. (See dwFileOffsetLow in https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-…) - On other systems? Who knows. 3. On macOS, a buffer successfully created with an offset crashes on read. I don't know why, it's exactly the same file, size and offset that works on Ubuntu, and the read is bounded. 4. Currently, offset doesn't change the buffer's size if unspecified, leading to crashes. I will be making a PR addressing this but still. 5. All of this makes offset unpractical to test, leading to all kinds of problems. So the problem is: this argument is a very low-level detail that requires significant knowledge of all platforms your code may be ever deployed to, even if strictly Ruby is used (no C API), with unexpectedly high footgun potential. I understand that IO::Buffer is a lower-level class, but this seems too much. I propose to make `offset` argument into a convenience for users, allowing any reasonable value (i.e inside the file). Behind the scenes, we can use the native offset for efficieny, on platforms where it works well, but the user API would be decoupled from this. However, I'm not particularly familiar with Ruby internals, so I can't tell how viable this is. -- https://bugs.ruby-lang.org/

2 4

[ruby-core:124443] [Ruby Bug#21828] An incorrect warning message related to `benchmark` is shown when using `benchmark-ips`
by y-yagi (Yuji Yaginuma) 11 Mar '26

11 Mar '26

Issue #21828 has been reported by y-yagi (Yuji Yaginuma). ---------------------------------------- Bug #21828: An incorrect warning message related to `benchmark` is shown when using `benchmark-ips` https://bugs.ruby-lang.org/issues/21828 * Author: y-yagi (Yuji Yaginuma) * Status: Open * ruby -v: ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ## Descrition When using `benchmark-ips` gem with Ruby 4.0.0, the warning related to `benchmark` gem is shown. ## Step to reproduce ```ruby # Gemfile # frozen_string_literal: true source "https://rubygems.org" gem "benchmark-ips" ``` ```ruby # script.rb require "benchmark/ips" ``` ```text $ bundle exec ruby -v script.rb ruby 4.0.0 (2025-12-25 revision 553f1675f3) +PRISM [x86_64-linux] script.rb:1: warning: benchmark/ips is found in benchmark, which is not part of the default gems since Ruby 4.0.0. You can add benchmark to your Gemfile or gemspec to fix this error. ``` ## Expected behavior The warning for `benchmark` isn't shown when using `benchmark-ips`. -- https://bugs.ruby-lang.org/

4 11