May 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:121918] [Ruby Bug#18119] Ractor crashes when instantiating classes
by jhawthorn (John Hawthorn) 08 May '25

08 May '25

Issue #18119 has been updated by jhawthorn (John Hawthorn). Assignee changed from ko1 (Koichi Sasada) to ractor ---------------------------------------- Bug #18119: Ractor crashes when instantiating classes https://bugs.ruby-lang.org/issues/18119#change-112987 * Author: peterzhu2118 (Peter Zhu) * Status: Assigned * Assignee: ractor * ruby -v: ruby 3.1.0dev (2021-08-19T08:44:48Z master 6963f8f743) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The following script crashes with a segfault (tested on Ubuntu 20.04 and macOS 11.5.2): ```ruby workers = (0...8).map do Ractor.new do loop do 100.times.map { Class.new } Ractor.yield nil end end end 100.times { Ractor.select(*workers) } ``` Crash error: ``` <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. test.rb:4: [BUG] Segmentation fault at 0x0000000000000040 ruby 3.1.0dev (2021-08-19T08:44:48Z master 6963f8f743) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0010 p:---- s:0033 e:000032 CFUNC :new c:0009 p:0011 s:0029 e:000028 BLOCK test.rb:4 [FINISH] c:0008 p:---- s:0026 e:000025 IFUNC c:0007 p:---- s:0023 e:000022 CFUNC :times c:0006 p:---- s:0020 e:000019 CFUNC :each c:0005 p:---- s:0017 e:000016 CFUNC :map c:0004 p:0007 s:0013 e:000012 BLOCK test.rb:4 [FINISH] c:0003 p:---- s:0010 e:000009 CFUNC :loop c:0002 p:0004 s:0006 e:000005 BLOCK test.rb:3 [FINISH] c:0001 p:---- s:0003 e:000002 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- test.rb:3:in `block (2 levels) in <main>' test.rb:3:in `loop' test.rb:4:in `block (3 levels) in <main>' test.rb:4:in `map' test.rb:4:in `each' test.rb:4:in `times' test.rb:4:in `block (4 levels) in <main>' test.rb:4:in `new' -- Machine register context ------------------------------------------------ RIP: 0x0000562c1f9cd2cb RBP: 0x00007f6c3736d378 RSP: 0x00007f6c368285f0 RAX: 0x00007f6c1c00e208 RBX: 0x00007f6c3736d378 RCX: 0x0000562c20ed8330 RDX: 0x0000000000000000 RDI: 0x00007f6c100095c0 RSI: 0x0000000000000000 R8: 0x0000000000000007 R9: 0x0000562c20ed8120 R10: 0x0000000000000022 R11: 0x0000562c21180760 R12: 0x0000000000000000 R13: 0x00007f6c3736c000 R14: 0x0000000000000000 R15: 0x00007f6c3736d378 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_print_backtrace+0x11) [0x562c1f995e38] ../vm_dump.c:759 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_bugreport) ../vm_dump.c:1041 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_bug_for_fatal_signal+0xec) [0x562c1f78a0bc] ../error.c:815 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(sigsegv+0x4d) [0x562c1f8ebcbd] ../signal.c:961 /lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f6c3b2c63c0] /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_remove_from_super_subclasses+0x2b) [0x562c1f9cd2cb] ../class.c:99 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(obj_free+0x37a) [0x562c1f7ae95a] ../gc.c:3123 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_plane_sweep+0x21) [0x562c1f7aef3d] ../gc.c:5322 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_page_sweep) ../gc.c:5464 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_sweep_step) ../gc.c:5630 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_heap_prepare_minimum_pages+0x0) [0x562c1f7afd94] ../gc.c:5834 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_sweep) ../gc.c:5837 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_marks+0x1c0) [0x562c1f7b3df8] ../gc.c:8144 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_start) ../gc.c:9013 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(heap_prepare+0x2f) [0x562c1f7b8b6f] ../gc.c:2131 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(heap_next_freepage) ../gc.c:2422 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(ractor_cache_slots) ../gc.c:2454 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_slowpath) ../gc.c:2495 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_slowpath_wb_protected) ../gc.c:2519 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_of0+0x5) [0x562c1f7b8ebd] ../gc.c:2562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_of) ../gc.c:2572 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_wb_protected_newobj_of) ../gc.c:2596 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(class_alloc+0x5) [0x562c1f9cd49e] ../class.c:185 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_boot) ../class.c:230 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(class_call_alloc_func+0x5) [0x562c1f84e5d3] ../object.c:2075 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_alloc) ../object.c:2047 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_new_instance_pass_kw) ../object.c:2120 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f96d6bc] ../vm_insnhelper.c:2989 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call_cfunc_with_frame) ../vm_insnhelper.c:2991 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_sendish+0x303) [0x562c1f978393] ../vm_insnhelper.c:4562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_exec_core+0xcd) [0x562c1f98316d] ../insns.def:775 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_exec+0x197) [0x562c1f978fc7] ../vm.c:2164 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(collect_i+0x12) [0x562c1fa27bf2] ../enum.c:608 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_pop_frame+0x0) [0x562c1f976ba8] ../vm_insnhelper.c:3795 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_yield_with_cfunc) ../vm_insnhelper.c:3796 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(invoke_block_from_c_bh+0x10) [0x562c1f97d0d3] ../vm.c:1359 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_yield) ../vm.c:1399 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_yield_0) ../vm_eval.c:1350 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_yield_1) ../vm_eval.c:1356 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(int_dotimes+0x5c) [0x562c1f83a49c] ../numeric.c:5014 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f97dd4f] ../vm_eval.c:135 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc_with_frame) ../vm_eval.c:137 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc) ../vm_eval.c:149 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_body) ../vm_eval.c:182 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_call0+0x1ea) [0x562c1f9812fa] ../vm_eval.c:72 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(iterate_method+0x3b) [0x562c1f981e9b] ../vm_eval.c:847 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_iterate0+0x101) [0x562c1f973001] ../vm_eval.c:1534 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_block_call_kw+0x76) [0x562c1f9731f6] ../vm_eval.c:1566 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(enumerator_block_call+0x59) [0x562c1fa358e9] ../enumerator.c:553 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f97dd4f] ../vm_eval.c:135 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc_with_frame) ../vm_eval.c:137 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc) ../vm_eval.c:149 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_body) ../vm_eval.c:182 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_call0+0x1ea) [0x562c1f9812fa] ../vm_eval.c:72 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(iterate_method+0x3b) [0x562c1f981e9b] ../vm_eval.c:847 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_iterate0+0x101) [0x562c1f973001] ../vm_eval.c:1534 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_lambda_call+0x75) [0x562c1f973295] ../vm_eval.c:1633 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(enum_collect+0x5b) [0x562c1fa29acb] ../enum.c:647 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f96d6bc] ../vm_insnhelper.c:2989 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call_cfunc_with_frame) ../vm_insnhelper.c:2991 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_sendish+0x303) [0x562c1f978393] ../vm_insnhelper.c:4562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_exec_core+0x130) [0x562c1f9831d0] ../insns.def:756 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_exec+0x197) [0x562c1f978fc7] ../vm.c:2164 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(invoke_block_from_c_bh+0x130) [0x562c1f97c85a] ../vm.c:1264 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_yield) ../vm.c:1399 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_yield_0) ../vm_eval.c:1350 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(loop_i) ../vm_eval.c:1449 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vrescue2+0x114) [0x562c1f794694] ../eval.c:1023 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_rescue2+0x8e) [0x562c1f79490e] ../eval.c:1000 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f96d6bc] ../vm_insnhelper.c:2989 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call_cfunc_with_frame) ../vm_insnhelper.c:2991 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_sendish+0x303) [0x562c1f978393] ../vm_insnhelper.c:4562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_exec_core+0x130) [0x562c1f9831d0] ../insns.def:756 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_exec+0x197) [0x562c1f978fc7] ../vm.c:2164 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_do_start_proc+0x294) [0x562c1f930f24] ../thread.c:716 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_do_start+0xc) [0x562c1f9336fc] ../thread.c:760 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_start_func_2) ../thread.c:835 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_native_cond_initialize+0x0) [0x562c1f933a09] ../thread_pthread.c:1051 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(register_cached_thread_and_wait) ../thread_pthread.c:1103 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_start_func_1) ../thread_pthread.c:1058 /lib/x86_64-linux-gnu/libpthread.so.0(0x9609) [0x7f6c3b2ba609] /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f6c3b044293] ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121917] [Ruby Bug#18119] Ractor crashes when instantiating classes
by peterzhu2118 (Peter Zhu) 08 May '25

08 May '25

Issue #18119 has been updated by peterzhu2118 (Peter Zhu). I have a fix here: https://github.com/ruby/ruby/pull/13284 ---------------------------------------- Bug #18119: Ractor crashes when instantiating classes https://bugs.ruby-lang.org/issues/18119#change-112986 * Author: peterzhu2118 (Peter Zhu) * Status: Assigned * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0dev (2021-08-19T08:44:48Z master 6963f8f743) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The following script crashes with a segfault (tested on Ubuntu 20.04 and macOS 11.5.2): ```ruby workers = (0...8).map do Ractor.new do loop do 100.times.map { Class.new } Ractor.yield nil end end end 100.times { Ractor.select(*workers) } ``` Crash error: ``` <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. test.rb:4: [BUG] Segmentation fault at 0x0000000000000040 ruby 3.1.0dev (2021-08-19T08:44:48Z master 6963f8f743) [x86_64-linux] -- Control frame information ----------------------------------------------- c:0010 p:---- s:0033 e:000032 CFUNC :new c:0009 p:0011 s:0029 e:000028 BLOCK test.rb:4 [FINISH] c:0008 p:---- s:0026 e:000025 IFUNC c:0007 p:---- s:0023 e:000022 CFUNC :times c:0006 p:---- s:0020 e:000019 CFUNC :each c:0005 p:---- s:0017 e:000016 CFUNC :map c:0004 p:0007 s:0013 e:000012 BLOCK test.rb:4 [FINISH] c:0003 p:---- s:0010 e:000009 CFUNC :loop c:0002 p:0004 s:0006 e:000005 BLOCK test.rb:3 [FINISH] c:0001 p:---- s:0003 e:000002 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- test.rb:3:in `block (2 levels) in <main>' test.rb:3:in `loop' test.rb:4:in `block (3 levels) in <main>' test.rb:4:in `map' test.rb:4:in `each' test.rb:4:in `times' test.rb:4:in `block (4 levels) in <main>' test.rb:4:in `new' -- Machine register context ------------------------------------------------ RIP: 0x0000562c1f9cd2cb RBP: 0x00007f6c3736d378 RSP: 0x00007f6c368285f0 RAX: 0x00007f6c1c00e208 RBX: 0x00007f6c3736d378 RCX: 0x0000562c20ed8330 RDX: 0x0000000000000000 RDI: 0x00007f6c100095c0 RSI: 0x0000000000000000 R8: 0x0000000000000007 R9: 0x0000562c20ed8120 R10: 0x0000000000000022 R11: 0x0000562c21180760 R12: 0x0000000000000000 R13: 0x00007f6c3736c000 R14: 0x0000000000000000 R15: 0x00007f6c3736d378 EFL: 0x0000000000010202 -- C level backtrace information ------------------------------------------- /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_print_backtrace+0x11) [0x562c1f995e38] ../vm_dump.c:759 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_bugreport) ../vm_dump.c:1041 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_bug_for_fatal_signal+0xec) [0x562c1f78a0bc] ../error.c:815 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(sigsegv+0x4d) [0x562c1f8ebcbd] ../signal.c:961 /lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f6c3b2c63c0] /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_remove_from_super_subclasses+0x2b) [0x562c1f9cd2cb] ../class.c:99 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(obj_free+0x37a) [0x562c1f7ae95a] ../gc.c:3123 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_plane_sweep+0x21) [0x562c1f7aef3d] ../gc.c:5322 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_page_sweep) ../gc.c:5464 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_sweep_step) ../gc.c:5630 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_heap_prepare_minimum_pages+0x0) [0x562c1f7afd94] ../gc.c:5834 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_sweep) ../gc.c:5837 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_marks+0x1c0) [0x562c1f7b3df8] ../gc.c:8144 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(gc_start) ../gc.c:9013 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(heap_prepare+0x2f) [0x562c1f7b8b6f] ../gc.c:2131 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(heap_next_freepage) ../gc.c:2422 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(ractor_cache_slots) ../gc.c:2454 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_slowpath) ../gc.c:2495 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_slowpath_wb_protected) ../gc.c:2519 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_of0+0x5) [0x562c1f7b8ebd] ../gc.c:2562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(newobj_of) ../gc.c:2572 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_wb_protected_newobj_of) ../gc.c:2596 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(class_alloc+0x5) [0x562c1f9cd49e] ../class.c:185 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_boot) ../class.c:230 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(class_call_alloc_func+0x5) [0x562c1f84e5d3] ../object.c:2075 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_alloc) ../object.c:2047 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_class_new_instance_pass_kw) ../object.c:2120 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f96d6bc] ../vm_insnhelper.c:2989 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call_cfunc_with_frame) ../vm_insnhelper.c:2991 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_sendish+0x303) [0x562c1f978393] ../vm_insnhelper.c:4562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_exec_core+0xcd) [0x562c1f98316d] ../insns.def:775 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_exec+0x197) [0x562c1f978fc7] ../vm.c:2164 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(collect_i+0x12) [0x562c1fa27bf2] ../enum.c:608 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_pop_frame+0x0) [0x562c1f976ba8] ../vm_insnhelper.c:3795 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_yield_with_cfunc) ../vm_insnhelper.c:3796 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(invoke_block_from_c_bh+0x10) [0x562c1f97d0d3] ../vm.c:1359 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_yield) ../vm.c:1399 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_yield_0) ../vm_eval.c:1350 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_yield_1) ../vm_eval.c:1356 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(int_dotimes+0x5c) [0x562c1f83a49c] ../numeric.c:5014 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f97dd4f] ../vm_eval.c:135 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc_with_frame) ../vm_eval.c:137 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc) ../vm_eval.c:149 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_body) ../vm_eval.c:182 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_call0+0x1ea) [0x562c1f9812fa] ../vm_eval.c:72 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(iterate_method+0x3b) [0x562c1f981e9b] ../vm_eval.c:847 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_iterate0+0x101) [0x562c1f973001] ../vm_eval.c:1534 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_block_call_kw+0x76) [0x562c1f9731f6] ../vm_eval.c:1566 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(enumerator_block_call+0x59) [0x562c1fa358e9] ../enumerator.c:553 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f97dd4f] ../vm_eval.c:135 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc_with_frame) ../vm_eval.c:137 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_cfunc) ../vm_eval.c:149 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call0_body) ../vm_eval.c:182 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_call0+0x1ea) [0x562c1f9812fa] ../vm_eval.c:72 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(iterate_method+0x3b) [0x562c1f981e9b] ../vm_eval.c:847 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_iterate0+0x101) [0x562c1f973001] ../vm_eval.c:1534 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_lambda_call+0x75) [0x562c1f973295] ../vm_eval.c:1633 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(enum_collect+0x5b) [0x562c1fa29acb] ../enum.c:647 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f96d6bc] ../vm_insnhelper.c:2989 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call_cfunc_with_frame) ../vm_insnhelper.c:2991 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_sendish+0x303) [0x562c1f978393] ../vm_insnhelper.c:4562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_exec_core+0x130) [0x562c1f9831d0] ../insns.def:756 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_exec+0x197) [0x562c1f978fc7] ../vm.c:2164 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(invoke_block_from_c_bh+0x130) [0x562c1f97c85a] ../vm.c:1264 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_yield) ../vm.c:1399 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_yield_0) ../vm_eval.c:1350 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(loop_i) ../vm_eval.c:1449 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vrescue2+0x114) [0x562c1f794694] ../eval.c:1023 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_rescue2+0x8e) [0x562c1f79490e] ../eval.c:1000 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_cfp_consistent_p+0x0) [0x562c1f96d6bc] ../vm_insnhelper.c:2989 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_call_cfunc_with_frame) ../vm_insnhelper.c:2991 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_sendish+0x303) [0x562c1f978393] ../vm_insnhelper.c:4562 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(vm_exec_core+0x130) [0x562c1f9831d0] ../insns.def:756 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_vm_exec+0x197) [0x562c1f978fc7] ../vm.c:2164 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_do_start_proc+0x294) [0x562c1f930f24] ../thread.c:716 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_do_start+0xc) [0x562c1f9336fc] ../thread.c:760 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_start_func_2) ../thread.c:835 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(rb_native_cond_initialize+0x0) [0x562c1f933a09] ../thread_pthread.c:1051 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(register_cached_thread_and_wait) ../thread_pthread.c:1103 /home/spin/src/github.com/Shopify/ruby-master/install/bin/ruby(thread_start_func_1) ../thread_pthread.c:1058 /lib/x86_64-linux-gnu/libpthread.so.0(0x9609) [0x7f6c3b2ba609] /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f6c3b044293] ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121916] [Ruby Feature#15408] Deprecate ObjectSpace._id2ref
by headius (Charles Nutter) 08 May '25

08 May '25

Issue #15408 has been updated by headius (Charles Nutter). @Dan0042 I think @Eregon covered what I was going to say, but I'd also like to know **why** you want `_id2ref` to stick around. There's generally better ways (more reliable, easier for VMs to implement) to everything I have seen it used for. ---------------------------------------- Feature #15408: Deprecate ObjectSpace._id2ref https://bugs.ruby-lang.org/issues/15408#change-112985 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: headius (Charles Nutter) ---------------------------------------- Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected. As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future. Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap. The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently. The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup. I propose that both methods should immediately be deprecated for removal in Ruby 3.0. * They do not do what people expect. * They cannot reliably do what they claim to do. * They eventually lead to difficult-to-diagnose bugs in every possible use case. Put simply, both methods have always been broken in MRI and making them unbroken would render them useless. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:120257] [Ruby master Bug#20957] RangeError on Array#values_at with negative ranges
by kyanagi (Kouhei Yanagita) 08 May '25

08 May '25

Issue #20957 has been reported by kyanagi (Kouhei Yanagita). ---------------------------------------- Bug #20957: RangeError on Array#values_at with negative ranges https://bugs.ruby-lang.org/issues/20957 * Author: kyanagi (Kouhei Yanagita) * Status: Open * ruby -v: ruby 3.4.0dev (2024-12-13T10:19:31Z master 3cb79d4082) +PRISM [arm64-darwin22] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- ``` [0, 1, 2, 3].values_at(10) #=> [nil] [0, 1, 2, 3].values_at(10..10) #=> [nil] [0, 1, 2, 3].values_at(-10) #=> [nil] [0, 1, 2, 3].values_at(-10..-10) #=> 'Array#values_at': -10..-10 out of range (RangeError) ``` Is this the intended behavior? I am aware that this behavior was recently added to the documentation, but I would like to confirm whether it is the intended behavior. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:121911] [Ruby Feature#15408] Deprecate ObjectSpace._id2ref
by Eregon (Benoit Daloze) 08 May '25

08 May '25

Issue #15408 has been updated by Eregon (Benoit Daloze). https://byroot.github.io/ruby/performance/2025/04/26/unlocking-ractors-obje… explains the problems of `_id2ref` in details, and how it changed. ---------------------------------------- Feature #15408: Deprecate ObjectSpace._id2ref https://bugs.ruby-lang.org/issues/15408#change-112980 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: headius (Charles Nutter) ---------------------------------------- Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected. As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future. Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap. The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently. The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup. I propose that both methods should immediately be deprecated for removal in Ruby 3.0. * They do not do what people expect. * They cannot reliably do what they claim to do. * They eventually lead to difficult-to-diagnose bugs in every possible use case. Put simply, both methods have always been broken in MRI and making them unbroken would render them useless. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121910] [Ruby Feature#15408] Deprecate ObjectSpace._id2ref
by Eregon (Benoit Daloze) 08 May '25

08 May '25

Issue #15408 has been updated by Eregon (Benoit Daloze). @Dan0042 It still is, CRuby has to keep a weak map of all objects for which the object_id was asked in case `_id2ref` is used. That's a big footprint and performance overhead. It's also impossible to implement this efficiently, as the original description already established. ---------------------------------------- Feature #15408: Deprecate ObjectSpace._id2ref https://bugs.ruby-lang.org/issues/15408#change-112979 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: headius (Charles Nutter) ---------------------------------------- Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected. As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future. Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap. The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently. The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup. I propose that both methods should immediately be deprecated for removal in Ruby 3.0. * They do not do what people expect. * They cannot reliably do what they claim to do. * They eventually lead to difficult-to-diagnose bugs in every possible use case. Put simply, both methods have always been broken in MRI and making them unbroken would render them useless. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121755] [Ruby Misc#21290] Unable to build ruby extension on Fedora 42 due to possible GCC 15 issues
by lukef (Luke Freeman) 08 May '25

08 May '25

Issue #21290 has been reported by lukef (Luke Freeman). ---------------------------------------- Misc #21290: Unable to build ruby extension on Fedora 42 due to possible GCC 15 issues https://bugs.ruby-lang.org/issues/21290 * Author: lukef (Luke Freeman) * Status: Open ---------------------------------------- At least one Ruby extension (ed25519) fails to build due to incompatibilities(?) with the core library headers on Fedora 42. When trying to build the ed25519 extension that is required for Kamal (and I guess Rails by association) there are errors relating to `bool` types. I'm assuming this is related to the inclusion of GCC 15 by default in version 42. For example: ``` <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/core/rtypeddata.h:578:15: note: ‘bool’ is defined in header ‘<stdbool.h>’; this is probably fixable by adding ‘#include <stdbool.h>’ In file included from <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/ruby.h:42: <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h:420:5: error: unknown type name ‘bool’ 420 | bool left; /**< Whether overflow happened or not. */ | ^~~~ <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h:65:1: note: ‘bool’ is defined in header ‘<stdbool.h>’; this is probably fixable by adding ‘#include <stdbool.h>’ 64 | #include "ruby/internal/stdckdint.h" +++ |+#include <stdbool.h> 65 | #include "ruby/internal/xmalloc.h" <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h: In function ‘rbimpl_size_mul_overflow’: <mise dir>/installs/ruby/3.4.3/include/ruby-3.4.0/ruby/internal/memory.h:574:49: error: ‘false’ undeclared (first use in this function) 574 | struct rbimpl_size_mul_overflow_tag ret = { false, 0, }; | ^~~~~ ``` I logged the relevant issue with Kamal and the ed25519 projects but figured the issue should be tracked here as anyone upgrading to Fedora 42 won't probably be able to use Rails if starting from scratch. Those issues are: - https://github.com/RubyCrypto/ed25519/issues/44 - https://github.com/basecamp/kamal/issues/1512 It's possible it is related to this issue also: https://bugs.ruby-lang.org/issues/21024. I have tried downgrading to Ruby 3.4.1 and even older, non-3.4 versions and the issue seems to be the same. I'm running: - Fedora 42 - Ruby 3.4+ Please let me know if you need additional information. -- https://bugs.ruby-lang.org/

7 7

[ruby-core:120710] [Ruby master Feature#21042] Add and expose Thread#memory_allocations memory allocation counters
by stanhu (Stan Hu) 08 May '25

08 May '25

Issue #21042 has been reported by stanhu (Stan Hu). ---------------------------------------- Feature #21042: Add and expose Thread#memory_allocations memory allocation counters https://bugs.ruby-lang.org/issues/21042 * Author: stanhu (Stan Hu) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- For the last 5 years, we've been patching our Ruby interpreter with https://github.com/ruby/ruby/pull/3978 in order to track memory allocations over time. This has been running in production at GitLab for a long time. I'd like to request approval for this patch to land upstream since we're getting tired of maintaining this patch, and this data seems like it would be generally useful. If this can be done via a C extension, let me know, and I can look at that. Copying from that pull request: ### Design This is designed to measure a memory allocations in a multi-threaded environments (concurrent requests processing) with an accurate information about allocated memory within a given execution context. The idea here is to provide as cheap as possible counter without an overhead of calling callbacks, and provide this information on a per-thread basis. ### Implementation This adds `Thread.current.memory_allocations`, which provides information about: * total_allocated_objects * total_malloc_bytes * total_mallocs This is based on a expectation, that allocation for a given thread always happens with a `rb_current_thread()` properly indicating a thread performing allocation. This measures total number of allocations as counters. Now, since the removal of objects is async and happening at random moment, the same cannot be said for deallocations, thus only allocations are tracked. -- https://bugs.ruby-lang.org/

5 5

[ruby-core:121889] [Ruby Feature#15408] Deprecate ObjectSpace._id2ref
by Dan0042 (Daniel DeLorme) 08 May '25

08 May '25

Issue #15408 has been updated by Dan0042 (Daniel DeLorme). The original reason to deprecate `_id2ref` is no longer relevant now that `object_id` is a monotonically-increasing ID. So I don't think it should be deprecated, unless there's some other benefit that wasn't mentioned above. ---------------------------------------- Feature #15408: Deprecate ObjectSpace._id2ref https://bugs.ruby-lang.org/issues/15408#change-112958 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: headius (Charles Nutter) ---------------------------------------- Ruby currently provides the object_id method to get a "identifier" for a given object. According to the documentation, this ID is the same for every object_id call against a given object, and guaranteed not to be the same as any other active (i.e. alive) object. However, no guarantee is made about the ID being reused for a future object after the original has been garbage collected. As a result, object_id can't be used to uniquely identify any object that might be garbage collected, since that ID may be associated with a completely different object in the future. Ruby also provides a method to go from an object_id to the object reference itself: ObjectSpace._id2ref. This method has been in Ruby for decades and is often used to implement a weak hashmap from ID to reference, since holding the ID will not keep the object alive. However due to the problems with object_id not actually being unique, it's possible for _id2ref to return a different object than originally had that ID as object slots are reused in the heap. The only way to implement object_id safely (with idempotency guarantees) would be to assign to all objects a monotonically-increasing ID. Alternatively, this ID could be assigned lazily only for those objects on which the code calls object_id. JRuby implements object_id in this way currently. The only way to implement _id2ref safely would be to have a mapping in memory from those monotonically-increasing IDs to the actual objects. This would have to be a weak mapping to prevent the objects from being garbage collected. JRuby currently only supports _id2ref via a flag, since the additional overhead of weakly tracking every requested object_id is extremely high. An alternative for MRI would be to implement _id2ref as a heap scan, as it is implemented in Rubinius. This would make it entirely unpractical due to the cost of scanning the heap for every ID lookup. I propose that both methods should immediately be deprecated for removal in Ruby 3.0. * They do not do what people expect. * They cannot reliably do what they claim to do. * They eventually lead to difficult-to-diagnose bugs in every possible use case. Put simply, both methods have always been broken in MRI and making them unbroken would render them useless. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121565] [Ruby Feature#21254] Inlining Class#new
by tenderlovemaking (Aaron Patterson) 07 May '25

07 May '25

Issue #21254 has been reported by tenderlovemaking (Aaron Patterson). ---------------------------------------- Feature #21254: Inlining Class#new https://bugs.ruby-lang.org/issues/21254 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- We would like to propose inlining YARV bytecode for speeding up object allocations, specifically inlining the `Class#new` method. In order to support inlining this method, we would like to introduce a new YARV instruction `opt_new`. This instruction will allocate an object if the default allocator is not overridden, otherwise it will jump to a “slow path” for calling a method. `Class#new` especially benefits from inlining for two reasons: 1. Calling `initialize` directly means we don't need to allocate a temporary hash for keyword arguments 2. We are able to use an inline cache when calling the `initialize` method The patch can be found [here](https://github.com/ruby/ruby/pull/13080), but please find implementation details below. ## Implementation Details This patch modifies the compiler to emit special instructions when it sees a callsite that uses “new”. Before this patch, calling `Object.new` would result in bytecode like this: ``` ruby --dump=insns -e'Object.new' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 opt_getconstant_path <ic:0 Object> ( 1)[Li] 0002 opt_send_without_block <calldata!mid:new, argc:0, ARGS_SIMPLE> 0004 leave ``` With this patch, the bytecode looks like this: ``` ./ruby --dump=insns -e'Object.new' == disasm: #<ISeq:<main>@-e:1 (1,0)-(1,10)> 0000 opt_getconstant_path <ic:0 Object> ( 1)[Li] 0002 putnil 0003 swap 0004 opt_new <calldata!mid:new, argc:0, ARGS_SIMPLE>, 11 0007 opt_send_without_block <calldata!mid:initialize, argc:0, FCALL|ARGS_SIMPLE> 0009 jump 14 0011 opt_send_without_block <calldata!mid:new, argc:0, ARGS_SIMPLE> 0013 swap 0014 pop 0015 leave ``` The new `opt_new` instruction checks whether or not the `new` implementation is the default “allocator” implementation. If it is the default allocator, then the instruction will allocate the object and call initialize passing parameters to initialize but not to `new`. If the method is not the default allocator implementation, it will jump to the normal method dispatch instructions. Performance Improvements This patch improves performance of all allocations that use the normal “new” method for allocation. Here are two examples (all of these benchmarks compare Ruby 3.4.2 against Ruby master with inlining patch): A simple `Object.new` in a hot loop improves by about 24%: ``` hyperfine "ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end'" "./ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end'" Benchmark 1: ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end' Time (mean ± σ): 436.6 ms ± 3.3 ms [User: 432.3 ms, System: 3.8 ms] Range (min … max): 430.5 ms … 442.6 ms 10 runs Benchmark 2: ./ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end' Time (mean ± σ): 351.1 ms ± 3.6 ms [User: 347.4 ms, System: 3.3 ms] Range (min … max): 343.9 ms … 357.4 ms 10 runs Summary ./ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end' ran 1.24 ± 0.02 times faster than ruby --disable-gems -e'i = 0; while i < 10_000_000; Object.new; i += 1; end' ``` Using a single keyword argument is improved by about 72%: ``` > hyperfine "ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end'" "./ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end'" Benchmark 1: ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end' Time (mean ± σ): 1.082 s ± 0.007 s [User: 1.074 s, System: 0.008 s] Range (min … max): 1.071 s … 1.091 s 10 runs Benchmark 2: ./ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end' Time (mean ± σ): 627.6 ms ± 4.8 ms [User: 622.6 ms, System: 4.5 ms] Range (min … max): 622.1 ms … 637.2 ms 10 runs Summary ./ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end' ran 1.72 ± 0.02 times faster than ruby --disable-gems -e'i = 0; while i < 10_000_000; Hash.new(capacity: 0); i += 1; end' ``` The performance increase depends on the number and type of parameters passed to `initialize`. For example, an `initialize` method that takes 3 parameters can see a speed improvement of ~3x: ``` aaron@tc-lan-adapter ~/g/ruby (inline-new)> cat test.rb class Foo def initialize a:, b:, c: end end i = 0 while i < 10_000_000 Foo.new(a: 1, b: 2, c: 3) Foo.new(a: 1, b: 2, c: 3) Foo.new(a: 1, b: 2, c: 3) i += 1 end aaron@tc-lan-adapter ~/g/ruby (inline-new)> hyperfine "ruby --disable-gems test.rb" "./ruby --disable-gems test.rb" Benchmark 1: ruby --disable-gems test.rb Time (mean ± σ): 3.700 s ± 0.033 s [User: 3.681 s, System: 0.018 s] Range (min … max): 3.636 s … 3.751 s 10 runs Benchmark 2: ./ruby --disable-gems test.rb Time (mean ± σ): 1.182 s ± 0.013 s [User: 1.173 s, System: 0.008 s] Range (min … max): 1.165 s … 1.203 s 10 runs Summary ./ruby --disable-gems test.rb ran 3.13 ± 0.04 times faster than ruby --disable-gems test.rb ``` One factor in the performance increase for keyword arguments is that inlining is able to eliminate the hash allocation when calling “through” the C implementation of `Class#new`: ``` aaron@tc-lan-adapter ~/g/ruby (inline-new)> cat test.rb class Foo def initialize a:, b:, c: end end def allocs x = GC.stat(:total_allocated_objects) yield GC.stat(:total_allocated_objects) - x end def test; allocs { Foo.new(a: 1, b: 2, c: 3) }; end test p test aaron@tc-lan-adapter ~/g/ruby (inline-new)> ruby -v test.rb ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] 2 aaron@tc-lan-adapter ~/g/ruby (inline-new)> ./ruby -v test.rb ruby 3.5.0dev (2025-04-03T13:03:19Z inline-new 567c54208c) +PRISM [arm64-darwin24] 1 ``` ## Memory Increase Of course this patch is not “free”. Inlining the method call adds extra YARV instructions. We estimate this patch increases `new` call sites by about 122 bytes: ``` aaron@tc-lan-adapter ~/g/ruby (inline-new)> cat test.rb require "objspace" class Foo def initialize end end def test Foo.new end puts ObjectSpace.memsize_of(RubyVM::InstructionSequence.of(method(:test))) aaron@tc-lan-adapter ~/g/ruby (inline-new)> ruby -v test.rb ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] 544 aaron@tc-lan-adapter ~/g/ruby (inline-new)> ./ruby -v test.rb ruby 3.5.0dev (2025-04-03T13:03:19Z inline-new 567c54208c) +PRISM [arm64-darwin24] 656 ``` We’ve tested this in Shopify’s monolith, comparing Ruby 3.4.2 and Ruby 3.5+inlining, and it seems to increase total ISEQ memesize by about 3.8mb (roughly 0.5% increase in ISEQ size): ``` irb(main):001> 737191972 - 733354388 => 3837584 ``` However, Ruby 3.5 has more overall ISEQ objects than Ruby 3.4.2: ``` aaron@Aarons-MacBook-Pro ~/Downloads> wc -l sizes-inline.txt 789545 sizes-inline.txt aaron@Aarons-MacBook-Pro ~/Downloads> wc -l sizes-3.4.txt 789479 sizes-3.4.txt ``` We see total heap size as reported by `memsize` to only increase by about 1MB: ``` irb(main):001> 3981075617 - 3979926505 => 1149112 ``` ## Changes to `caller` This patch changes `caller` reporting in the `initialize` method: ``` aaron@tc-lan-adapter ~/g/ruby (inline-new)> cat test.rb require "objspace" class Foo def initialize puts caller end end def test Foo.new end test aaron@tc-lan-adapter ~/g/ruby (inline-new)> ruby -v test.rb ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] test.rb:10:in 'Class#new' test.rb:10:in 'Object#test' test.rb:13:in '<main>' aaron@tc-lan-adapter ~/g/ruby (inline-new)> ./ruby -v test.rb ruby 3.5.0dev (2025-04-03T13:03:19Z inline-new 567c54208c) +PRISM [arm64-darwin24] test.rb:10:in 'Object#test' test.rb:13:in '<main>' ``` As you can see in the above output, the `Class#new` frame is eliminated. I'm not sure if anyone really cares about this frame. We've tested this patch in Shopify's CI, and didn't find any code that depends on this callstack. However, this patch did require [changes to ERB for emitting warnings](https://github.com/ruby/ruby/pull/13080/files#diff-7624f95f521b33…. That said, eliminating the frame also has the side-effect of making some of our allocation tracing tools a little more useful: ``` aaron@tc-lan-adapter ~/g/ruby (inline-new)> cat test.rb require "objspace" class Foo def test Object.new end end ObjectSpace.trace_object_allocations do obj = Foo.new.test puts ObjectSpace.allocation_class_path(obj) puts ObjectSpace.allocation_method_id(obj) end aaron@tc-lan-adapter ~/g/ruby (inline-new)> ruby -v test.rb ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] Class new aaron@tc-lan-adapter ~/g/ruby (inline-new)> ./ruby -v test.rb ruby 3.5.0dev (2025-04-07T19:40:59Z inline-new 2cf0efa18e) +PRISM [arm64-darwin24] Foo test ``` Before inlining, `ObjectSpace` would report the allocation class path and method id as `Class#new` which isn't very helpful. With the inlining patch, we can see that the object is allocated in `Foo#test`. ## Summary I think the overall memory increase is modest, and the change to `caller` is acceptable especially given the performance increase this patch provides. -- https://bugs.ruby-lang.org/

6 11