* [Feature #22226] Ractor: class/module ownership -- restrict modification to the Ractor that created it (ko1) * This proposal reduce the exceptions. In most case, there are no problem. * [Feature #22227] Per-Ractor GC: collect each ...ko1 (Koichi Sasada)
Companion PR: https://github.com/ruby/ruby/pull/18194 --- ## Abstract This proposal makes the default GC operate per Ractor. Each Ractor owns an objspace (a private heap) and collects it on its own thread without stopping any...ko1 (Koichi Sasada)
## Abstract Every class/module records the Ractor that created it as its *owner*. Only the owner Ractor can modify it. Reading is unchanged and allowed from any Ractor. This replaces several ad-hoc "main Ractor only" rules with a ...ko1 (Koichi Sasada)
make_shareable_check_shareable() assumes allow_frozen_shareable_p() can only fail for T_DATA and dereferences RTYPEDDATA_TYPE() right after the check. The VM_ASSERT documenting that assumption is compiled out in a release build, so maki...ko1 (Koichi Sasada)
A frozen IO used to pass Ractor.make_shareable, but the result is not useful and not sound: * Almost nothing works on it. read, gets, seek, eof? and sync= all raise FrozenError because they update the buffered state in rb_io; only ...ko1 (Koichi Sasada)
TRY_WITH_GC guards its retry-GC branch with gc_allowed (which reflects the current ractor's malloc_gc_disabled, set while a ractor lock is held), but called objspace_malloc_gc_stress() unconditionally. Under GC.stress, a malloc inside a...ko1 (Koichi Sasada)
The splat rebuild in compile_massign_lhs passes the arena-allocated INSN (iobj) to RB_OBJ_WRITTEN (since f2286925f0). iobj is not a heap object, so the barrier touches the page it happens to land on, which is undefined. It is harmless ...ko1 (Koichi Sasada)
The assertion for change_c_events < 0 compares ruby_vm_c_events_enabled against -change_iseq_events instead of -change_c_events, so it fires on a normal case where the iseq-event decrement happens to exceed the number of enabled C events...ko1 (Koichi Sasada)
I agree that the current behavior is a Ractor bug. In fact, this is one of the blockers preventing us from removing the "experimental" warning from Ractor. These variables should be thread-local. The main implementation challenge is h...ko1 (Koichi Sasada)
rb_managed_id_table stores its rb_id_table body as embedded data (RUBY_TYPED_EMBEDDABLE), so managed_id_table_ptr returns a pointer interior to the wrapper object. rb_managed_id_table_foreach, _foreach_values, and _dup hand that interio...ko1 (Koichi Sasada)