Skip to content

[pull] master from ruby:master#984

Merged
pull[bot] merged 5 commits intoturkdevops:masterfrom
ruby:master
May 5, 2026
Merged

[pull] master from ruby:master#984
pull[bot] merged 5 commits intoturkdevops:masterfrom
ruby:master

Conversation

@pull
Copy link
Copy Markdown

@pull pull Bot commented May 5, 2026

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

nozomemein and others added 5 commits May 4, 2026 17:45
Avoid receiver shapes near the embedded/heap boundary in the
polymorphic getivar tests.

Make both receivers clearly heap-backed so stats and dev builds still
exercise distinct @foo slots without depending on embedded_p().
The old setivar opt tests depended on embedded-capacity boundaries that
vary between dev and stats builds.

Compute the boundary from GC::INTERNAL_CONSTANTS and construct receivers
so the tests reliably cover shape transition and heap-backed self
upgrade paths.
The old test snapshot depended on the second write crossing the
embedded-capacity boundary, even though the behavior under test was
just the shape transition across two ivar writes.

Warm the class to two ivars and assert the natural specialized path
instead, so the test covers the intended shape updates without relying
on GC-derived capacity behavior.
Stop deriving the embedded-capacity boundary from GC internals in
`upgrade_self_type_to_heap_after_setivar`.

Instead, use self-consistency checks to keep the snapshot only on builds
where five ivars stay embedded and the next write overflows into the
heap-backed self upgrade path.
Since EC is thread-local, we previously used rb_gc_worker_thread_set_vm_context
in MMTk worker threads to temporarily set the EC. However, this was inelegant
and also occasionally caused crashes when marking threads/fibers for the
current EC since it will mark the current machine stack twice (once during
root marking and once for the fiber). However, since the machine
stack is actively being used, the contents may be different when marking
the fiber. Since all objects on the machine stack are pinned, this may
cause an unpinned object to be pinned, which is not allowed in Immix.

The following crash can be observed:

    Object 0x200fffbc7d8 is trying to pin 0x200ffc80188
      0: mmtk_ruby::handle_gc_thread_panic
      1: mmtk_ruby::set_panic_hook::{{closure}}
      2: <alloc::boxed::Box<dyn for<'a, 'b> core::ops::function::Fn<(&'a std::panic::PanicHookInfo<'b>,), Output = ()> + core::marker::Sync + core::marker::Send> as core::ops::function::Fn<(&std::panic::PanicHookInfo,)>>::call
                at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/alloc/src/boxed.rs:2254:9
      3: std::panicking::panic_with_hook
                at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/std/src/panicking.rs:833:13
      4: std::panicking::panic_handler::{closure#0}
                at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/std/src/panicking.rs:698:13
      5: std::sys::backtrace::__rust_end_short_backtrace::<std::panicking::panic_handler::{closure#0}, !>
                at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/std/src/sys/backtrace.rs:182:18
      6: __rustc::rust_begin_unwind
                at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/std/src/panicking.rs:689:5
      7: core::panicking::panic_fmt
                at /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/core/src/panicking.rs:80:14
      8: <mmtk_ruby::scanning::VMScanning as mmtk::vm::scanning::Scanning<mmtk_ruby::Ruby>>::scan_object_and_trace_edges::{{closure}}
      9: mmtk_ruby::abi::ObjectClosure::c_function_registered
      10: rb_mmtk_call_object_closure
                at gc/mmtk/mmtk.c:976:19
      11: rb_gc_impl_mark_and_pin
                at gc/mmtk/mmtk.c:1008:5
      12: rb_gc_impl_mark_and_pin
                at gc/mmtk/mmtk.c:1004:1
      13: gc_mark_maybe_internal
                at gc.c:2908:5
      14: gc_mark_maybe_internal
                at gc.c:2906:1
      15: gc_mark_maybe_each_location
                at gc.c:2939:5
      16: gc_mark_maybe_each_location
                at gc.c:2937:1
      17: each_location
                at gc.c:2924:9
      18: each_location_ptr
                at gc.c:2933:5
      19: each_location_ptr
                at gc.c:2930:1
      20: rb_gc_mark_machine_context
                at gc.c:3200:5
      21: rb_execution_context_mark
                at vm.c:3768:9
      22: cont_mark
                at cont.c:1155:5
      23: fiber_mark
                at cont.c:1284:5
      24: rb_mmtk_call_gc_mark_children
                at gc/mmtk/mmtk.c:318:5
      25: <mmtk_ruby::scanning::VMScanning as mmtk::vm::scanning::Scanning<mmtk_ruby::Ruby>>::scan_object_and_trace_edges::{{closure}}
@pull pull Bot locked and limited conversation to collaborators May 5, 2026
@pull pull Bot added the ⤵️ pull label May 5, 2026
@pull pull Bot merged commit 06fc5c2 into turkdevops:master May 5, 2026
1 of 3 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants