Add a failing YJIT bootstrap test for argument delegation #6

casperisfine · 2024-04-20T07:47:57Z

@0

This patch optimizes forwarding callers and callees. It only optimizes methods that only take `...` as their parameter, and then pass `...` to other calls. Calls it optimizes look like this: ```ruby def bar(a) = a def foo(...) = bar(...) # optimized foo(123) ``` ```ruby def bar(a) = a def foo(...) = bar(1, 2, ...) # optimized foo(123) ``` ```ruby def bar(*a) = a def foo(...) list = [1, 2] bar(*list, ...) # optimized end foo(123) ``` All variants of the above but using `super` are also optimized, including a bare super like this: ```ruby def foo(...) super end ``` This patch eliminates intermediate allocations made when calling methods that accept `...`. We can observe allocation elimination like this: ```ruby def m x = GC.stat(:total_allocated_objects) yield GC.stat(:total_allocated_objects) - x end def bar(a) = a def foo(...) = bar(...) def test m { foo(123) } end test p test # allocates 1 object on master, but 0 objects with this patch ``` ```ruby def bar(a, b:) = a + b def foo(...) = bar(...) def test m { foo(1, b: 2) } end test p test # allocates 2 objects on master, but 0 objects with this patch ``` How does it work? ----------------- This patch works by using a dynamic stack size when passing forwarded parameters to callees. The caller's info object (known as the "CI") contains the stack size of the parameters, so we pass the CI object itself as a parameter to the callee. When forwarding parameters, the forwarding ISeq uses the caller's CI to determine how much stack to copy, then copies the caller's stack before calling the callee. The CI at the forwarded call site is adjusted using information from the caller's CI. I think this description is kind of confusing, so let's walk through an example with code. ```ruby def delegatee(a, b) = a + b def delegator(...) delegatee(...) # CI2 (FORWARDING) end def caller delegator(1, 2) # CI1 (argc: 2) end ``` Before we call the delegator method, the stack looks like this: ``` Executing Line | Code | Stack ---------------+---------------------------------------+-------- 1| def delegatee(a, b) = a + b | self 2| | 1 3| def delegator(...) | 2 4| # | 5| delegatee(...) # CI2 (FORWARDING) | 6| end | 7| | 8| def caller | -> 9| delegator(1, 2) # CI1 (argc: 2) | 10| end | ``` The ISeq for `delegator` is tagged as "forwardable", so when `caller` calls in to `delegator`, it writes `CI1` on to the stack as a local variable for the `delegator` method. The `delegator` method has a special local called `...` that holds the caller's CI object. Here is the ISeq disasm fo `delegator`: ``` == disasm: #<ISeq:delegator@-e:1 (1,0)-(1,39)> local table (size: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1]) [ 1] "..."@0 0000 putself ( 1)[LiCa] 0001 getlocal_WC_0 "..."@0 0003 send <calldata!mid:delegatee, argc:0, FCALL|FORWARDING>, nil 0006 leave [Re] ``` The local called `...` will contain the caller's CI: CI1. Here is the stack when we enter `delegator`: ``` Executing Line | Code | Stack ---------------+---------------------------------------+-------- 1| def delegatee(a, b) = a + b | self 2| | 1 3| def delegator(...) | 2 -> 4| # | CI1 (argc: 2) 5| delegatee(...) # CI2 (FORWARDING) | cref_or_me 6| end | specval 7| | type 8| def caller | 9| delegator(1, 2) # CI1 (argc: 2) | 10| end | ``` The CI at `delegatee` on line 5 is tagged as "FORWARDING", so it knows to memcopy the caller's stack before calling `delegatee`. In this case, it will memcopy self, 1, and 2 to the stack before calling `delegatee`. It knows how much memory to copy from the caller because `CI1` contains stack size information (argc: 2). Before executing the `send` instruction, we push `...` on the stack. The `send` instruction pops `...`, and because it is tagged with `FORWARDING`, it knows to memcopy (using the information in the CI it just popped): ``` == disasm: #<ISeq:delegator@-e:1 (1,0)-(1,39)> local table (size: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1]) [ 1] "..."@0 0000 putself ( 1)[LiCa] 0001 getlocal_WC_0 "..."@0 0003 send <calldata!mid:delegatee, argc:0, FCALL|FORWARDING>, nil 0006 leave [Re] ``` Instruction 001 puts the caller's CI on the stack. `send` is tagged with FORWARDING, so it reads the CI and _copies_ the callers stack to this stack: ``` Executing Line | Code | Stack ---------------+---------------------------------------+-------- 1| def delegatee(a, b) = a + b | self 2| | 1 3| def delegator(...) | 2 4| # | CI1 (argc: 2) -> 5| delegatee(...) # CI2 (FORWARDING) | cref_or_me 6| end | specval 7| | type 8| def caller | self 9| delegator(1, 2) # CI1 (argc: 2) | 1 10| end | 2 ``` The "FORWARDING" call site combines information from CI1 with CI2 in order to support passing other values in addition to the `...` value, as well as perfectly forward splat args, kwargs, etc. Since we're able to copy the stack from `caller` in to `delegator`'s stack, we can avoid allocating objects. I want to do this to eliminate object allocations for delegate methods. My long term goal is to implement `Class#new` in Ruby and it uses `...`. I was able to implement `Class#new` in Ruby [here](ruby#9289). If we adopt the technique in this patch, then we can optimize allocating objects that take keyword parameters for `initialize`. For example, this code will allocate 2 objects: one for `SomeObject`, and one for the kwargs: ```ruby SomeObject.new(foo: 1) ``` If we combine this technique, plus implement `Class#new` in Ruby, then we can reduce allocations for this common operation. Co-Authored-By: John Hawthorn <[email protected]> Co-Authored-By: Alan Wu <[email protected]>

It's very unlikely, so lets do it last

We don't want to do any assertions in this case, we just want to quit

tenderlove · 2024-04-20T16:14:41Z

Wild. Thought this would be covered by the other tests I added. Thank you.

casperisfine · 2024-04-21T06:48:05Z

@tenderlove sorry, I reduced the test case too much. The actual trigger seem to be: send(:method) calling into a receiver(...), with YJIT.

casperisfine · 2024-04-21T06:48:20Z

Should fail CI now.

We're seeing a crash during shutdown in rb_gc_impl_objspace_free because it's running lazy sweeping during shutdown. It appears that it's due to `finalizing` being set, which causes GC to not be aborted and not disabled which causes it to be in lazy sweeping at shutdown. The full stack trace is: #6 rb_bug (fmt=fmt@entry=0x5643b8ebde78 "lazy sweeping underway when freeing object space") at error.c:1095 ruby#7 0x00005643b8a3c697 in rb_gc_impl_objspace_free (objspace_ptr=<optimized out>) at gc/default.c:9507 ruby#8 0x00005643b8c269eb in ruby_vm_destruct (vm=0x7e2fdc84d000) at vm.c:3141 ruby#9 0x00005643b8a5147b in rb_ec_cleanup (ec=<optimized out>, ex=<optimized out>) at eval.c:263 ruby#10 0x00005643b8a51c93 in ruby_run_node (n=<optimized out>) at eval.c:319 ruby#11 0x00005643b8a4c7c7 in rb_main (argv=0x7fffef15e7f8, argc=18) at ./main.c:43 ruby#12 main (argc=<optimized out>, argv=<optimized out>) at ./main.c:62

During compilation, we write keyword default values into the iseq, so we should mark it to ensure it does not get GC'd. This might fix issues on ASAN like http://ci.rvm.jp/logfiles/brlog.trunk_asan.20240927-194923 ==805257==ERROR: AddressSanitizer: use-after-poison on address 0x7b7e5e3e2828 at pc 0x5e09ac4822f8 bp 0x7ffde56b0140 sp 0x7ffde56b0138 READ of size 8 at 0x7b7e5e3e2828 thread T0 #0 0x5e09ac4822f7 in RB_BUILTIN_TYPE include/ruby/internal/value_type.h:191:30 #1 0x5e09ac4822f7 in rbimpl_RB_TYPE_P_fastpath include/ruby/internal/value_type.h:352:19 #2 0x5e09ac4822f7 in gc_mark gc/default.c:4488:9 #3 0x5e09ac51011e in rb_iseq_mark_and_move iseq.c:361:17 #4 0x5e09ac4b85c4 in rb_imemo_mark_and_move imemo.c:386:9 #5 0x5e09ac467544 in rb_gc_mark_children gc.c:2508:9 #6 0x5e09ac482c24 in gc_mark_children gc/default.c:4673:5 ruby#7 0x5e09ac482c24 in gc_mark_stacked_objects gc/default.c:4694:9 ruby#8 0x5e09ac482c24 in gc_mark_stacked_objects_all gc/default.c:4732:12 ruby#9 0x5e09ac48c7f9 in gc_marks_rest gc/default.c:5755:9 ruby#10 0x5e09ac48c7f9 in gc_marks gc/default.c:5870:9 ruby#11 0x5e09ac48c7f9 in gc_start gc/default.c:6517:13

fill_lines is passed -1 for offset, which causes it to read the -1 index of traces. This is not valid memory as -1 is reading before the trace global variable in rb_print_backtrace. This code comes from commit 99d1f5f, where there used to be special handling for the -1 index. We can see this error in ASAN: ==71037==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00010157abf8 at pc 0x00010116f3b8 bp 0x00016f92c3b0 sp 0x00016f92c3a8 READ of size 8 at 0x00010157abf8 thread T0 #0 0x10116f3b4 in debug_info_read addr2line.c:1945 #1 0x10116cc90 in fill_lines addr2line.c:2497 #2 0x101169dbc in rb_dump_backtrace_with_lines addr2line.c:2635 #3 0x100e56788 in rb_print_backtrace vm_dump.c:825 #4 0x100e56db4 in rb_vm_bugreport vm_dump.c:1155 #5 0x100734dc4 in rb_bug_without_die error.c:1085 #6 0x100734ae4 in rb_bug error.c:109

[Bug #20921] When we create a cache entry for a constant, the following sequence of events could happen: - vm_track_constant_cache is called to insert a constant cache. - In vm_track_constant_cache, we first look up the ST table for the ID of the constant. Assume the ST table exists because another iseq also holds a cache entry for this ID. - We then insert into this ST table with the iseq_inline_constant_cache. - However, while inserting into this ST table, it allocates memory, which could trigger a GC. Assume that it does trigger a GC. - The GC frees the one and only other iseq that holds a cache entry for this ID. - In remove_from_constant_cache, it will appear that the ST table is now empty because there are no more iseq with cache entries for this ID, so we free the ST table. - We complete GC and continue our st_insert. However, this ST table has been freed so we now have a use-after-free. This issue is very hard to reproduce, because it requires that the GC runs at a very specific time. However, we can make it show up by applying this patch which runs GC right before the st_insert to mimic the st_insert triggering a GC: diff --git a/vm_insnhelper.c b/vm_insnhelper.c index 3cb23f0..a93998136a 100644 --- a/vm_insnhelper.c +++ b/vm_insnhelper.c @@ -6338,6 +6338,10 @@ vm_track_constant_cache(ID id, void *ic) rb_id_table_insert(const_cache, id, (VALUE)ics); } + if (id == rb_intern("MyConstant")) rb_gc(); + st_insert(ics, (st_data_t) ic, (st_data_t) Qtrue); } And if we run this script: Object.const_set("MyConstant", "Hello!") my_proc = eval("-> { MyConstant }") my_proc.call my_proc = eval("-> { MyConstant }") my_proc.call We can see that ASAN outputs a use-after-free error: ==36540==ERROR: AddressSanitizer: heap-use-after-free on address 0x606000049528 at pc 0x000102f3ceac bp 0x00016d607a70 sp 0x00016d607a68 READ of size 8 at 0x606000049528 thread T0 #0 0x102f3cea8 in do_hash st.c:321 #1 0x102f3ddd0 in rb_st_insert st.c:1132 #2 0x103140700 in vm_track_constant_cache vm_insnhelper.c:6345 #3 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 #4 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 #5 0x1030bc1e0 in vm_exec_core insns.def:263 #6 0x1030b55fc in rb_vm_exec vm.c:2585 ruby#7 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 ruby#8 0x102a82588 in rb_ec_exec_node eval.c:281 ruby#9 0x102a81fe0 in ruby_run_node eval.c:319 ruby#10 0x1027f3db4 in rb_main main.c:43 ruby#11 0x1027f3bd4 in main main.c:68 ruby#12 0x183900270 (<unknown module>) 0x606000049528 is located 8 bytes inside of 56-byte region [0x606000049520,0x606000049558) freed by thread T0 here: #0 0x104174d40 in free+0x98 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54d40) #1 0x102ada89c in rb_gc_impl_free default.c:8183 #2 0x102ada7dc in ruby_sized_xfree gc.c:4507 #3 0x102ac4d34 in ruby_xfree gc.c:4518 #4 0x102f3cb34 in rb_st_free_table st.c:663 #5 0x102bd52d8 in remove_from_constant_cache iseq.c:119 #6 0x102bbe2cc in iseq_clear_ic_references iseq.c:153 ruby#7 0x102bbd2a0 in rb_iseq_free iseq.c:166 ruby#8 0x102b32ed0 in rb_imemo_free imemo.c:564 ruby#9 0x102ac4b44 in rb_gc_obj_free gc.c:1407 ruby#10 0x102af4290 in gc_sweep_plane default.c:3546 ruby#11 0x102af3bdc in gc_sweep_page default.c:3634 ruby#12 0x102aeb140 in gc_sweep_step default.c:3906 ruby#13 0x102aeadf0 in gc_sweep_rest default.c:3978 ruby#14 0x102ae4714 in gc_sweep default.c:4155 ruby#15 0x102af8474 in gc_start default.c:6484 ruby#16 0x102afbe30 in garbage_collect default.c:6363 ruby#17 0x102ad37f0 in rb_gc_impl_start default.c:6816 ruby#18 0x102ad3634 in rb_gc gc.c:3624 ruby#19 0x1031406ec in vm_track_constant_cache vm_insnhelper.c:6342 #20 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 ruby#21 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 ruby#22 0x1030bc1e0 in vm_exec_core insns.def:263 ruby#23 0x1030b55fc in rb_vm_exec vm.c:2585 ruby#24 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 ruby#25 0x102a82588 in rb_ec_exec_node eval.c:281 ruby#26 0x102a81fe0 in ruby_run_node eval.c:319 ruby#27 0x1027f3db4 in rb_main main.c:43 ruby#28 0x1027f3bd4 in main main.c:68 ruby#29 0x183900270 (<unknown module>) previously allocated by thread T0 here: #0 0x104174c04 in malloc+0x94 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x54c04) #1 0x102ada0ec in rb_gc_impl_malloc default.c:8198 #2 0x102acee44 in ruby_xmalloc gc.c:4438 #3 0x102f3c85c in rb_st_init_table_with_size st.c:571 #4 0x102f3c900 in rb_st_init_table st.c:600 #5 0x102f3c920 in rb_st_init_numtable st.c:608 #6 0x103140698 in vm_track_constant_cache vm_insnhelper.c:6337 ruby#7 0x1030b91d8 in vm_ic_track_const_chain vm_insnhelper.c:6356 ruby#8 0x1030b8cf8 in rb_vm_opt_getconstant_path vm_insnhelper.c:6424 ruby#9 0x1030bc1e0 in vm_exec_core insns.def:263 ruby#10 0x1030b55fc in rb_vm_exec vm.c:2585 ruby#11 0x1030fe0ac in rb_iseq_eval_main vm.c:2851 ruby#12 0x102a82588 in rb_ec_exec_node eval.c:281 ruby#13 0x102a81fe0 in ruby_run_node eval.c:319 ruby#14 0x1027f3db4 in rb_main main.c:43 ruby#15 0x1027f3bd4 in main main.c:68 ruby#16 0x183900270 (<unknown module>) This commit fixes this bug by adding a inserting_constant_cache_id field to the VM, which stores the ID that is currently being inserted and, in remove_from_constant_cache, we don't free the ST table for ID equal to this one. Co-Authored-By: Alan Wu <[email protected]>

Just a first step. Have a read, and let's improve it together. Close: GH-6

[Bug #18119] When we create classes, it pushes the class to the subclass list of the superclass. This access needs to be synchronized because multiple Ractors may be creating classes with the same superclass, which would cause race conditions and cause the linked list to be corrupted. For example, we can reproduce with this script crashing: 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) } With ASAN enabled, we can see that there are use-after-free errors: ==176013==ERROR: AddressSanitizer: heap-use-after-free on address 0x5030000974f0 at pc 0x62f9e56f892d bp 0x7a503f1ffd90 sp 0x7a503f1ffd88 WRITE of size 8 at 0x5030000974f0 thread T4 #0 0x62f9e56f892c in rb_class_remove_from_super_subclasses class.c:149:24 #1 0x62f9e58c9dd2 in rb_gc_obj_free gc.c:1262:9 #2 0x62f9e58f6e19 in gc_sweep_plane gc/default/default.c:3450:21 #3 0x62f9e58f686a in gc_sweep_page gc/default/default.c:3535:13 #4 0x62f9e58f12b4 in gc_sweep_step gc/default/default.c:3810:9 #5 0x62f9e58ed2a7 in gc_sweep gc/default/default.c:4058:13 #6 0x62f9e58fac93 in gc_start gc/default/default.c:6402:13 ruby#7 0x62f9e58e8b69 in heap_prepare gc/default/default.c:2032:13 ruby#8 0x62f9e58e8b69 in heap_next_free_page gc/default/default.c:2255:9 ruby#9 0x62f9e58e8b69 in newobj_cache_miss gc/default/default.c:2362:38 ... 0x5030000974f0 is located 16 bytes inside of 24-byte region [0x5030000974e0,0x5030000974f8) freed by thread T4 here: #0 0x62f9e562f28a in free (miniruby+0x1fd28a) (BuildId: 5ad6d9e7cec8318df6726ea5ce34d3c76d0d0233) #1 0x62f9e58ca2ab in rb_gc_impl_free gc/default/default.c:8102:9 #2 0x62f9e58ca2ab in ruby_sized_xfree gc.c:5029:13 #3 0x62f9e58ca2ab in ruby_xfree gc.c:5040:5 #4 0x62f9e56f88e6 in rb_class_remove_from_super_subclasses class.c:152:9 #5 0x62f9e58c9dd2 in rb_gc_obj_free gc.c:1262:9 #6 0x62f9e58f6e19 in gc_sweep_plane gc/default/default.c:3450:21 ruby#7 0x62f9e58f686a in gc_sweep_page gc/default/default.c:3535:13 ruby#8 0x62f9e58f12b4 in gc_sweep_step gc/default/default.c:3810:9 ruby#9 0x62f9e58ed2a7 in gc_sweep gc/default/default.c:4058:13 ... previously allocated by thread T5 here: #0 0x62f9e562f70d in calloc (miniruby+0x1fd70d) (BuildId: 5ad6d9e7cec8318df6726ea5ce34d3c76d0d0233) #1 0x62f9e58c8e1a in calloc1 gc/default/default.c:1472:12 #2 0x62f9e58c8e1a in rb_gc_impl_calloc gc/default/default.c:8138:5 #3 0x62f9e58c8e1a in ruby_xcalloc_body gc.c:4964:12 #4 0x62f9e58c8e1a in ruby_xcalloc gc.c:4958:34 #5 0x62f9e56f906e in push_subclass_entry_to_list class.c:88:13 #6 0x62f9e56f906e in rb_class_subclass_add class.c:111:38 ruby#7 0x62f9e56f906e in RCLASS_SET_SUPER internal/class.h:257:9 ruby#8 0x62f9e56fca7a in make_metaclass class.c:786:5 ruby#9 0x62f9e59db982 in rb_class_initialize object.c:2101:5

In commit d42b9ff, an optimization was introduced that can speed up Regexp#match by 15% when it matches with strings of different encodings. This optimization, however, does not work across ractors. To fix this, we only use the optimization if no ractors have been started. In the future, we could use atomics for the reference counting if we find it's needed and if it's more performant. The backtrace of the misbehaving native thread: ``` * frame #0: 0x0000000189c94388 libsystem_kernel.dylib`__pthread_kill + 8 frame #1: 0x0000000189ccd88c libsystem_pthread.dylib`pthread_kill + 296 frame #2: 0x0000000189bd6c60 libsystem_c.dylib`abort + 124 frame #3: 0x0000000189adb174 libsystem_malloc.dylib`malloc_vreport + 892 frame #4: 0x0000000189adec90 libsystem_malloc.dylib`malloc_report + 64 frame #5: 0x0000000189ae321c libsystem_malloc.dylib`___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED + 32 frame #6: 0x00000001001c3be4 ruby`onig_free_body(reg=0x000000012d84b660) at regcomp.c:5663:5 frame ruby#7: 0x00000001001ba828 ruby`rb_reg_prepare_re(re=4748462304, str=4748451168) at re.c:1680:13 frame ruby#8: 0x00000001001bac58 ruby`rb_reg_onig_match(re=4748462304, str=4748451168, match=(ruby`reg_onig_search [inlined] rbimpl_RB_TYPE_P_fastpath at value_type.h:349:14 ruby`reg_onig_search [inlined] rbimpl_rstring_getmem at rstring.h:391:5 ruby`reg_onig_search at re.c:1781:5), args=0x000000013824b168, regs=0x000000013824b150) at re.c:1708:20 frame ruby#9: 0x00000001001baefc ruby`rb_reg_search_set_match(re=4748462304, str=4748451168, pos=<unavailable>, reverse=0, set_backref_str=1, set_match=0x0000000000000000) at re.c:1809:27 frame ruby#10: 0x00000001001bae80 ruby`rb_reg_search0(re=<unavailable>, str=<unavailable>, pos=<unavailable>, reverse=<unavailable>, set_backref_str=<unavailable>, match=<unavailable>) at re.c:1861:12 [artificial] frame ruby#11: 0x0000000100230b90 ruby`rb_pat_search0(pat=<unavailable>, str=<unavailable>, pos=<unavailable>, set_backref_str=<unavailable>, match=<unavailable>) at string.c:6619:16 [artificial] frame ruby#12: 0x00000001002287f4 ruby`rb_str_sub_bang [inlined] rb_pat_search(pat=4748462304, str=4748451168, pos=0, set_backref_str=1) at string.c:6626:12 frame ruby#13: 0x00000001002287dc ruby`rb_str_sub_bang(argc=1, argv=0x00000001381280d0, str=4748451168) at string.c:6668:11 frame ruby#14: 0x000000010022826c ruby`rb_str_sub ``` You can reproduce this by running: ``` RUBY_TESTOPTS="--name=/test_str_capitalize/" make test-all TESTS=test/ruby/test_m17n.comb ``` However, you need to run it with multiple ractors at once. Co-authored-by: jhawthorn <[email protected]>

`name` is used via `RSTRING_PTR` within rb_str_catf, which may allocate and thus potentially trigger GC. Although `name` is still referenced by a local variable, the compiler might optimize away the reference before the GC sees it, especially under aggressive optimization or when debugging tools like ASAN are used. This patch adds an explicit `RB_GC_GUARD` to ensure `name` is kept alive until after the last use. While it's not certain this is the root cause of the following observed use-after-poison ASAN error, I believe this fix is indeed needed and hopefully a likely candidate for preventing the error. ``` ==1960369==ERROR: AddressSanitizer: use-after-poison on address 0x7ec6a00f1d88 at pc 0x5fb5bcafcf2e bp 0x7ffcc1178cb0 sp 0x7ffcc1178470 READ of size 61 at 0x7ec6a00f1d88 thread T0 #0 0x5fb5bcafcf2d in __asan_memcpy (/tmp/ruby/build/trunk_asan/ruby+0x204f2d) (BuildId: 6d92c84a27b87cfd253c38eeb552593f215ffb3d) #1 0x5fb5bcde1fa5 in memcpy /usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10 #2 0x5fb5bcde1fa5 in ruby_nonempty_memcpy /tmp/ruby/src/trunk_asan/include/ruby/internal/memory.h:758:16 #3 0x5fb5bcde1fa5 in ruby__sfvwrite /tmp/ruby/src/trunk_asan/sprintf.c:1083:9 #4 0x5fb5bcde1521 in BSD__sprint /tmp/ruby/src/trunk_asan/vsnprintf.c:318:8 #5 0x5fb5bcde0fbc in BSD_vfprintf /tmp/ruby/src/trunk_asan/vsnprintf.c:1215:3 #6 0x5fb5bcdde4b1 in ruby_vsprintf0 /tmp/ruby/src/trunk_asan/sprintf.c:1164:5 ruby#7 0x5fb5bcddd648 in rb_str_vcatf /tmp/ruby/src/trunk_asan/sprintf.c:1234:5 ruby#8 0x5fb5bcddd648 in rb_str_catf /tmp/ruby/src/trunk_asan/sprintf.c:1245:11 ruby#9 0x5fb5bcf97c67 in location_format /tmp/ruby/src/trunk_asan/vm_backtrace.c:462:9 ruby#10 0x5fb5bcf97c67 in location_to_str /tmp/ruby/src/trunk_asan/vm_backtrace.c:493:12 ruby#11 0x5fb5bcf90a37 in location_to_str_dmyarg /tmp/ruby/src/trunk_asan/vm_backtrace.c:795:12 ruby#12 0x5fb5bcf90a37 in backtrace_collect /tmp/ruby/src/trunk_asan/vm_backtrace.c:786:28 ruby#13 0x5fb5bcf90a37 in backtrace_to_str_ary /tmp/ruby/src/trunk_asan/vm_backtrace.c:804:9 ruby#14 0x5fb5bcf90a37 in rb_backtrace_to_str_ary /tmp/ruby/src/trunk_asan/vm_backtrace.c:816:9 ruby#15 0x5fb5bd335b25 in exc_backtrace /tmp/ruby/src/trunk_asan/error.c:1904:15 ruby#16 0x5fb5bd335b25 in rb_get_backtrace /tmp/ruby/src/trunk_asan/error.c:1924:16 ``` https://ci.rvm.jp/results/trunk_asan@ruby-sp1/5810304

This change addresses the following ASAN error: ``` ==1973462==ERROR: AddressSanitizer: heap-use-after-free on address 0x5110002117dc at pc 0x749c307c8a65 bp 0x7ffc3af331d0 sp 0x7ffc3af331c8 READ of size 4 at 0x5110002117dc thread T0 #0 0x749c307c8a64 in rb_getaddrinfo /tmp/ruby/src/trunk_asan/ext/socket/raddrinfo.c:564:14 #1 0x749c307c8a64 in rsock_getaddrinfo /tmp/ruby/src/trunk_asan/ext/socket/raddrinfo.c:1008:21 #2 0x749c307cac48 in rsock_addrinfo /tmp/ruby/src/trunk_asan/ext/socket/raddrinfo.c:1049:12 #3 0x749c307b10ae in init_inetsock_internal /tmp/ruby/src/trunk_asan/ext/socket/ipsocket.c:62:23 #4 0x562c5b2e327e in rb_ensure /tmp/ruby/src/trunk_asan/eval.c:1080:18 #5 0x749c307aafd4 in rsock_init_inetsock /tmp/ruby/src/trunk_asan/ext/socket/ipsocket.c:1318:12 #6 0x749c307b3b78 in tcp_svr_init /tmp/ruby/src/trunk_asan/ext/socket/tcpserver.c:39:12 ``` Fixed to avoid accessing memory that has already been freed after calling `free_getaddrinfo_arg`.

During Ruby's shutdown, we no longer need to check the fstr of the symbol because we don't use the fstr anymore for freeing the symbol. This can also fix the following ASAN error: ==2721247==ERROR: AddressSanitizer: use-after-poison on address 0x75fa90a627b8 at pc 0x64a7b06fb4bc bp 0x7ffdf95ba9b0 sp 0x7ffdf95ba9a8 READ of size 8 at 0x75fa90a627b8 thread T0 #0 0x64a7b06fb4bb in RB_BUILTIN_TYPE include/ruby/internal/value_type.h:191:30 #1 0x64a7b06fb4bb in rb_gc_shutdown_call_finalizer_p gc.c:357:18 #2 0x64a7b06fb4bb in rb_gc_impl_shutdown_call_finalizer gc/default/default.c:3045:21 #3 0x64a7b06fb4bb in rb_objspace_call_finalizer gc.c:1739:5 #4 0x64a7b06ca1b2 in rb_ec_finalize eval.c:165:5 #5 0x64a7b06ca1b2 in rb_ec_cleanup eval.c:256:5 #6 0x64a7b06c98a3 in ruby_cleanup eval.c:179:12

If we malloc when the current Ractor is locked, we can deadlock because GC requires VM lock and Ractor barrier. If another Ractor is waiting on this Ractor lock, then it will deadlock because the other Ractor will never join the barrier. For example, this script deadlocks: r = Ractor.new do loop do Ractor::Port.new end end 100000.times do |i| r.send(nil) puts i end On debug builds, it fails with this assertion error: vm_sync.c:75: Assertion Failed: vm_lock_enter:cr->sync.locked_by != rb_ractor_self(cr) On non-debug builds, we can see that it deadlocks in the debugger: Main Ractor: frame #3: 0x000000010021fdc4 miniruby`rb_native_mutex_lock(lock=<unavailable>) at thread_pthread.c:115:14 frame #4: 0x0000000100193eb8 miniruby`ractor_send0 [inlined] ractor_lock(r=<unavailable>, file=<unavailable>, line=1180) at ractor.c:73:5 frame #5: 0x0000000100193eb0 miniruby`ractor_send0 [inlined] ractor_send_basket(ec=<unavailable>, rp=0x0000000131092840, b=0x000000011c63de80, raise_on_error=true) at ractor_sync.c:1180:5 frame #6: 0x0000000100193eac miniruby`ractor_send0(ec=<unavailable>, rp=0x0000000131092840, obj=4, move=<unavailable>, raise_on_error=true) at ractor_sync.c:1211:5 Second Ractor: frame #2: 0x00000001002208d0 miniruby`rb_ractor_sched_barrier_start [inlined] rb_native_cond_wait(cond=<unavailable>, mutex=<unavailable>) at thread_pthread.c:221:13 frame #3: 0x00000001002208cc miniruby`rb_ractor_sched_barrier_start(vm=0x000000013180d600, cr=0x0000000131093460) at thread_pthread.c:1438:13 frame #4: 0x000000010028a328 miniruby`rb_vm_barrier at vm_sync.c:262:13 [artificial] frame #5: 0x00000001000dfa6c miniruby`gc_start [inlined] rb_gc_vm_barrier at gc.c:179:5 frame #6: 0x00000001000dfa68 miniruby`gc_start [inlined] gc_enter(objspace=0x000000013180fc00, event=gc_enter_event_start, lock_lev=<unavailable>) at default.c:6636:9 frame ruby#7: 0x00000001000dfa48 miniruby`gc_start(objspace=0x000000013180fc00, reason=<unavailable>) at default.c:6361:5 frame ruby#8: 0x00000001000e3fd8 miniruby`objspace_malloc_increase_body [inlined] garbage_collect(objspace=0x000000013180fc00, reason=512) at default.c:6341:15 frame ruby#9: 0x00000001000e3fa4 miniruby`objspace_malloc_increase_body [inlined] garbage_collect_with_gvl(objspace=0x000000013180fc00, reason=512) at default.c:6741:16 frame ruby#10: 0x00000001000e3f88 miniruby`objspace_malloc_increase_body(objspace=0x000000013180fc00, mem=<unavailable>, new_size=<unavailable>, old_size=<unavailable>, type=<unavailable>) at default.c:8007:13 frame ruby#11: 0x00000001000e3c44 miniruby`rb_gc_impl_malloc [inlined] objspace_malloc_fixup(objspace=0x000000013180fc00, mem=0x000000011c700000, size=12582912) at default.c:8085:5 frame ruby#12: 0x00000001000e3c30 miniruby`rb_gc_impl_malloc(objspace_ptr=0x000000013180fc00, size=12582912) at default.c:8182:12 frame ruby#13: 0x00000001000d4584 miniruby`ruby_xmalloc [inlined] ruby_xmalloc_body(size=<unavailable>) at gc.c:5128:12 frame ruby#14: 0x00000001000d4568 miniruby`ruby_xmalloc(size=<unavailable>) at gc.c:5118:34 frame ruby#15: 0x00000001001eb184 miniruby`rb_st_init_existing_table_with_size(tab=0x000000011c2b4b40, type=<unavailable>, size=<unavailable>) at st.c:559:39 frame ruby#16: 0x00000001001ebc74 miniruby`rebuild_table_if_necessary [inlined] rb_st_init_table_with_size(type=0x00000001004f4a78, size=524287) at st.c:585:5 frame ruby#17: 0x00000001001ebc5c miniruby`rebuild_table_if_necessary [inlined] rebuild_table(tab=0x000000013108e2f0) at st.c:753:19 frame ruby#18: 0x00000001001ebbfc miniruby`rebuild_table_if_necessary(tab=0x000000013108e2f0) at st.c:1125:9 frame ruby#19: 0x00000001001eba08 miniruby`rb_st_insert(tab=0x000000013108e2f0, key=262144, value=4767566624) at st.c:1143:5 frame #20: 0x0000000100194b84 miniruby`ractor_port_initialzie [inlined] ractor_add_port(r=0x0000000131093460, id=262144) at ractor_sync.c:399:9 frame ruby#21: 0x0000000100194b58 miniruby`ractor_port_initialzie [inlined] ractor_port_init(rpv=4750065560, r=0x0000000131093460) at ractor_sync.c:87:5 frame ruby#22: 0x0000000100194b34 miniruby`ractor_port_initialzie(self=4750065560) at ractor_sync.c:103:12

We need to free the current_block_exits in parse_program when we're done with it to prevent memory leaks. This fixes the following memory leak detected when running Ruby using `RUBY_FREE_AT_EXIT=1 ruby -nc -e "break"`: Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x5bd3c5bc66c8 in realloc (miniruby+0x616c8) (BuildId: ruby/prism@ba6a96e5a060) #1 0x5bd3c5f91fd9 in pm_node_list_grow prism/templates/src/node.c.erb:35:40 #2 0x5bd3c5f91e9d in pm_node_list_append prism/templates/src/node.c.erb:48:9 #3 0x5bd3c6001fa0 in parse_block_exit prism/prism.c:15788:17 #4 0x5bd3c5fee155 in parse_expression_prefix prism/prism.c:19221:50 #5 0x5bd3c5fe9970 in parse_expression prism/prism.c:22235:23 #6 0x5bd3c5fe0586 in parse_statements prism/prism.c:13976:27 ruby#7 0x5bd3c5fd6792 in parse_program prism/prism.c:22508:40 ruby/prism@fdf9b8d24a

When RUBYOPT is invalid, it raises an error which causes moreswitches to leak memory. It can be seen when building with LSAN enabled: $ RUBY_FREE_AT_EXIT=1 RUBYOPT=f ruby ruby: invalid option -f (-h will show valid options) (RuntimeError) Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x618cef8efa23 in malloc (miniruby+0x64a23) #1 0x618cefa0e8d8 in rb_gc_impl_malloc gc/default/default.c:8182:5 #2 0x618cef9f7f01 in ruby_xmalloc2_body gc.c:5182:12 #3 0x618cef9f7eac in ruby_xmalloc2 gc.c:5176:34 #4 0x618cefb547b2 in moreswitches ruby.c:919:18 #5 0x618cefb526fe in process_options ruby.c:2350:9 #6 0x618cefb524ac in ruby_process_options ruby.c:3202:12 ruby#7 0x618cef9dc11f in ruby_options eval.c:119:16 ruby#8 0x618cef8f2fb5 in rb_main main.c:42:26 ruby#9 0x618cef8f2f59 in main main.c:62:12

We were seeing errors like: ``` * thread ruby#8, stop reason = EXC_BAD_ACCESS (code=1, address=0x803) * frame #0: 0x00000001001fe944 ruby`rb_st_lookup(tab=0x00000000000007fb, key=1, value=0x00000001305b7490) at st.c:1066:22 frame #1: 0x000000010002d658 ruby`remove_class_from_subclasses [inlined] class_get_subclasses_for_ns(tbl=0x00000000000007fb, ns_id=1) at class.c:604:9 frame #2: 0x000000010002d650 ruby`remove_class_from_subclasses(tbl=0x00000000000007fb, ns_id=1, klass=4754039232) at class.c:620:34 frame #3: 0x000000010002c8a8 ruby`rb_class_classext_free_subclasses(ext=0x000000011b5ce1d8, klass=4754039232, replacing=<unavailable>) at class.c:700:9 frame #4: 0x000000010002c760 ruby`rb_class_classext_free(klass=4754039232, ext=0x000000011b5ce1d8, is_prime=true) at class.c:105:5 frame #5: 0x00000001000e770c ruby`classext_free(ext=<unavailable>, is_prime=<unavailable>, namespace=<unavailable>, arg=<unavailable>) at gc.c:1231:5 [artificial] frame #6: 0x000000010002d178 ruby`rb_class_classext_foreach(klass=<unavailable>, func=(ruby`classext_free at gc.c:1228), arg=0x00000001305b75c0) at class.c:518:5 frame ruby#7: 0x00000001000e745c ruby`rb_gc_obj_free(objspace=0x000000012500c400, obj=4754039232) at gc.c:1282:9 frame ruby#8: 0x00000001000e70d4 ruby`gc_sweep_plane(objspace=0x000000012500c400, heap=<unavailable>, p=4754039232, bitset=4095, ctx=0x00000001305b76e8) at default.c:3482:21 frame ruby#9: 0x00000001000e6e9c ruby`gc_sweep_page(objspace=0x000000012500c400, heap=0x000000012500c540, ctx=0x00000001305b76e8) at default.c:3567:13 frame ruby#10: 0x00000001000e51d0 ruby`gc_sweep_step(objspace=0x000000012500c400, heap=0x000000012500c540) at default.c:3848:9 frame ruby#11: 0x00000001000e1880 ruby`gc_continue [inlined] gc_sweep_continue(objspace=0x000000012500c400, sweep_heap=0x000000012500c540) at default.c:3931:13 frame ruby#12: 0x00000001000e1754 ruby`gc_continue(objspace=0x000000012500c400, heap=0x000000012500c540) at default.c:2037:9 frame ruby#13: 0x00000001000e10bc ruby`newobj_cache_miss [inlined] heap_prepare(objspace=0x000000012500c400, heap=0x000000012500c540) at default.c:2056:5 frame ruby#14: 0x00000001000e1074 ruby`newobj_cache_miss [inlined] heap_next_free_page(objspace=0x000000012500c400, heap=0x000000012500c540) at default.c:2280:9 frame ruby#15: 0x00000001000e106c ruby`newobj_cache_miss(objspace=0x000000012500c400, cache=0x0000600001b00300, heap_idx=2, vm_locked=false) at default.c:2387:38 frame ruby#16: 0x00000001000e0d28 ruby`newobj_alloc(objspace=<unavailable>, cache=<unavailable>, heap_idx=<unavailable>, vm_locked=<unavailable>) at default.c:2411:15 [artificial] frame ruby#17: 0x00000001000d7214 ruby`newobj_of [inlined] rb_gc_impl_new_obj(objspace_ptr=<unavailable>, cache_ptr=<unavailable>, klass=<unavailable>, flags=<unavailable>, wb_protected=<unavailable>, alloc_size=<unavailable>) at default.c:2490:15 frame ruby#18: 0x00000001000d719c ruby`newobj_of(cr=<unavailable>, klass=4313971728, flags=258, wb_protected=<unavailable>, size=<unavailable>) at gc.c:995:17 frame ruby#19: 0x00000001000d73ec ruby`rb_wb_protected_newobj_of(ec=<unavailable>, klass=<unavailable>, flags=<unavailable>, size=<unavailable>) at gc.c:1044:12 [artificial] frame #20: 0x0000000100032d34 ruby`class_alloc0(type=<unavailable>, klass=4313971728, namespaceable=<unavailable>) at class.c:803:5 ```

We don't decrement the super and module subclasses count for iclasses that are having their classext replaced. This causes the reference count to be incorrect and leak memory. The following script demonstrates the memory leak: module Foo refine(Object) do define_method(:<=) {} end end class Bar include Comparable end With RUBY_FREE_AT_EXIT and ASAN, we can see many memory leaks, including: Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x599f715adca2 in calloc (miniruby+0x64ca2) #1 0x599f716bd779 in calloc1 gc/default/default.c:1495:12 #2 0x599f716d1370 in rb_gc_impl_calloc gc/default/default.c:8216:5 #3 0x599f716b8ab1 in ruby_xcalloc_body gc.c:5221:12 #4 0x599f716b269c in ruby_xcalloc gc.c:5215:34 #5 0x599f715eab23 in class_alloc0 class.c:790:22 #6 0x599f715e4bec in class_alloc class.c:836:12 ruby#7 0x599f715e60c9 in module_new class.c:1693:17 ruby#8 0x599f715e60a2 in rb_module_new class.c:1701:12 ruby#9 0x599f715e6303 in rb_define_module class.c:1733:14 ruby#10 0x599f715ebc5f in Init_Comparable compar.c:315:22 ruby#11 0x599f716e35f5 in rb_call_inits inits.c:32:5 ruby#12 0x599f7169cbfd in ruby_setup eval.c:88:9 ruby#13 0x599f7169cdac in ruby_init eval.c:100:17 ruby#14 0x599f715b0fa9 in rb_main main.c:41:5 ruby#15 0x599f715b0f59 in main main.c:62:12 ruby#16 0x739b2f02a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 ruby#17 0x739b2f02a28a in __libc_start_main csu/../csu/libc-start.c:360:3 ruby#18 0x599f7157c424 in _start (miniruby+0x33424)

These tests use NM threads but NT is not freed for MN thread, causing it to be reported as memory leaks in LSAN. For example: #1 0x62ee7bc67e99 in calloc1 gc/default/default.c:1495:12 #2 0x62ee7bc7ba00 in rb_gc_impl_calloc gc/default/default.c:8216:5 #3 0x62ee7bc631d1 in ruby_xcalloc_body gc.c:5221:12 #4 0x62ee7bc5cdbc in ruby_xcalloc gc.c:5215:34 #5 0x62ee7bdea4c6 in native_thread_alloc thread_pthread.c:2187:35 #6 0x62ee7bdec31b in native_thread_check_and_create_shared thread_pthread_mn.c:429:39 ruby#7 0x62ee7bdea484 in native_thread_create_shared thread_pthread_mn.c:531:12 ruby#8 0x62ee7bdea1da in native_thread_create thread_pthread.c:2403:16 ruby#9 0x62ee7bdde2eb in thread_create_core thread.c:884:11 ruby#10 0x62ee7bde4466 in thread_initialize thread.c:992:16

We need the VM barrier in rb_gc_impl_before_fork to stop the other Ractors because otherwise they could be allocating objects in the fast path which could be calling mmtk_add_obj_free_candidate. Since mmtk_add_obj_free_candidate acquires a lock on obj_free_candidates in weak_proc.rs, this lock may not be released in the child process after the Ractor dies. For example, the following script demonstrates the issue: puts "Hello #{Process.pid}" 100.times do |i| puts "i = #{i}" Ractor.new(i) do |j| puts "Ractor #{j} hello" 1000.times do |i| s = "#{j}-#{i}" end Ractor.receive puts "Ractor #{j} goodbye" end pid = fork { } puts "Child pid is #{pid}" _, status = Process.waitpid2 pid puts status.success? end puts "Goodbye" In the child process, we can see that it is stuck trying to acquire the lock on obj_free_candidates: #5 0x00007192bfb53f10 in mmtk_ruby::weak_proc::WeakProcessor::get_all_obj_free_candidates (self=0x7192c0657498 <mmtk_ruby::BINDING+72>) at src/weak_proc.rs:52 #6 0x00007192bfa634c3 in mmtk_ruby::api::mmtk_get_all_obj_free_candidates () at src/api.rs:295 ruby#7 0x00007192bfa61d50 in rb_gc_impl_shutdown_call_finalizer (objspace_ptr=0x578c17abfc50) at gc/mmtk/mmtk.c:1032 ruby#8 0x0000578c1601e48e in rb_ec_finalize (ec=0x578c17ac06d0) at eval.c:166 ruby#9 rb_ec_cleanup (ec=<optimized out>, ex=<optimized out>) at eval.c:257 ruby#10 0x0000578c1601ebf6 in ruby_cleanup (ex=<optimized out>) at eval.c:180 ruby#11 ruby_stop (ex=<optimized out>) at eval.c:292 ruby#12 0x0000578c16127124 in rb_f_fork (obj=<optimized out>) at process.c:4291 ruby#13 rb_f_fork (obj=<optimized out>) at process.c:4281 ruby/mmtk@eb4b229858

In rb_gc_impl_before_fork, it locks the VM and barriers all the Ractors before calling mmtk_before_fork. However, since rb_mmtk_block_for_gc is a barrier point, one or more Ractors could be paused there. However, mmtk_before_fork is not compatible with that because it assumes that the MMTk workers are idle, but the workers are not idle because they are busy working on a GC. This commit essentially implements a trylock. It will optimistically lock but will release the lock if it detects that any other Ractors are waiting in rb_mmtk_block_for_gc. For example, the following script demonstrates the issue: puts "Hello #{Process.pid}" 100.times do |i| puts "i = #{i}" Ractor.new(i) do |j| puts "Ractor #{j} hello" 1000.times do |i| s = "#{j}-#{i}" end Ractor.receive puts "Ractor #{j} goodbye" end pid = fork { } puts "Child pid is #{pid}" _, status = Process.waitpid2 pid puts status.success? end puts "Goodbye" We can see the MMTk worker thread is waiting to start the GC: #4 0x00007ffff66538b1 in rb_mmtk_stop_the_world () at gc/mmtk/mmtk.c:101 #5 0x00007ffff6d04caf in mmtk_ruby::collection::{impl#0}::stop_all_mutators<mmtk::scheduler::gc_work::{impl#14}::do_work::{closure_env#0}<mmtk::plan::immix::gc_work::ImmixGCWorkContext<mmtk_ruby::Ruby, 0>>> (_tls=..., mutator_visitor=...) at src/collection.rs:23 However, the mutator thread is stuck in mmtk_before_fork trying to stop that worker thread: #4 0x00007ffff6c0b621 in std::sys::thread::unix::Thread::join () at library/std/src/sys/thread/unix.rs:134 #5 0x00007ffff6658b6e in std::thread::JoinInner<()>::join<()> (self=...) #6 0x00007ffff6658d4c in std::thread::JoinHandle<()>::join<()> (self=...) ruby#7 0x00007ffff665795e in mmtk_ruby::binding::RubyBinding::join_all_gc_threads (self=0x7ffff72462d0 <mmtk_ruby::BINDING+8>) at src/binding.rs:115 ruby#8 0x00007ffff66561a8 in mmtk_ruby::api::mmtk_before_fork () at src/api.rs:309 ruby#9 0x00007ffff66556ff in rb_gc_impl_before_fork (objspace_ptr=0x555555d17980) at gc/mmtk/mmtk.c:1054 ruby#10 0x00005555556bbc3e in rb_gc_before_fork () at gc.c:5429 ruby/mmtk@1a629504a7

tenderlove and others added 6 commits April 19, 2024 09:35

Move forwarding conditional

b9e0d6b

It's very unlikely, so lets do it last

bail earlier

e91376d

We don't want to do any assertions in this case, we just want to quit

do not compile forwardable iseqs

1abe569

reduce diff

8763508

reduce diff

93c71fe

Add a failing YJIT bootstrap test for argument delegation

a689c97

casperisfine force-pushed the speed-forward-yjit-test branch from f00f9d3 to a689c97 Compare April 21, 2024 06:47

tenderlove force-pushed the speed-forward branch 2 times, most recently from 46ef870 to 063df23 Compare April 24, 2024 22:24

tenderlove force-pushed the speed-forward branch from 354f9d7 to 92a12fd Compare May 2, 2024 18:41

tenderlove force-pushed the speed-forward branch from 92a12fd to ee95d84 Compare May 10, 2024 22:30

tenderlove force-pushed the speed-forward branch 5 times, most recently from 84a07fe to dc970fc Compare May 30, 2024 21:51

tenderlove force-pushed the speed-forward branch 7 times, most recently from 6d234be to 83a1cd8 Compare June 7, 2024 20:00

tenderlove force-pushed the speed-forward branch 3 times, most recently from d43476d to 7eef045 Compare June 18, 2024 15:36

tenderlove pushed a commit that referenced this pull request Apr 25, 2025

Add explainer for YARV frame layout

b6e4b37

Just a first step. Have a read, and let's improve it together. Close: GH-6

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add a failing YJIT bootstrap test for argument delegation #6

Add a failing YJIT bootstrap test for argument delegation #6

Uh oh!

casperisfine commented Apr 20, 2024

Uh oh!

tenderlove commented Apr 20, 2024

Uh oh!

casperisfine commented Apr 21, 2024

Uh oh!

casperisfine commented Apr 21, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Add a failing YJIT bootstrap test for argument delegation #6

Are you sure you want to change the base?

Add a failing YJIT bootstrap test for argument delegation #6

Uh oh!

Conversation

casperisfine commented Apr 20, 2024

Uh oh!

tenderlove commented Apr 20, 2024

Uh oh!

casperisfine commented Apr 21, 2024

Uh oh!

casperisfine commented Apr 21, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants