Skip to content

Conversation

@pull
Copy link

@pull pull bot commented Dec 19, 2025

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 : )

luke-gruber and others added 20 commits December 18, 2025 13:51
`encoded_iseq_trace_instrument` is safe to call in a ractor if the iseq
is new. In that case, the VM lock is not taken. This assertion was added in
4fb537b.
Previously when using a JIT and Ractors at the same time with debug
assertions turned on this could rarely fail with:

    vm_core.h:1448: Assertion Failed: VM_ENV_FLAGS:FIXNUM_P(flags)

When using Ractors, any time the VM lock is acquired, that may join a
barrier as another Ractor initiates GC. This could be made to happen
reliably by replacing the invalidation with a call to rb_gc().

This assertion failure happens because

    VM_STACK_ENV_WRITE(ep, 0, (VALUE)env);

Is setting VM_ENV_DATA_INDEX_FLAGS to the environment, which is not a
valid set of flags (it should be a fixnum). Although we update cfp->ep,
rb_execution_context_mark will also mark the PREV_EP, and until the
recursive calls to vm_make_env_each all finish the "next" ep may still
be pointing to the stack env we've just escaped.

I'm not completely sure why we need to store this on the stack - why is
setting cfp->ep not enough? I'm also not sure why
rb_execution_context_mark needs to mark the prev_ep.
We receive the ec as argument, it's much cheaper to pass it
around that to look it up again.
If the queue was allocated without calling initialize,
`ary` will be `0`.
Allows to remove some duplicated code like szqueue_length, etc.
[Bug #21793]

To fix a naming conflict on solaris.
* Ractor.yield no longer exists
* Ractor.shareable_proc returns a copy of the given proc
* Improve wording for monitoring/unmonitoring ports
Some TYPEDDATA objects allocate struct fields using the GC right after
they get created, and in that case the VM can try to perform a GC and join
a barrier if another ractor started one. If we're dumping the heap in another
ractor, this acquires a barrier and it will call the `rb_obj_memsize` function on this
object. We can't assume these struct fields are non-null. This also goes for C extensions,
which may cause problems with heap dumping from a ractor if their memsize functions aren't
coded correctly to check for NULL fields. Because dumping the heap from a ractor is likely a
rare scenario and it has only recently been introduced, we'll have to see how this works in
practice and if it causes bugs.
This is easier to access as ec->ractor_id instead of pointer-chasing through
ec->thread->ractor->ractor_id

Co-authored-by: Luke Gruber <luke.gru@gmail.com>
Co-authored-by: Luke Gruber <luke.gru@gmail.com>
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>

YJIT: Support calling bmethods in Ractors

Co-authored-by: Luke Gruber <luke.gru@gmail.com>

Suggestion from Alan
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>
This commit adds a new pack format command `R` and `r` for unsigned and
signed LEB128 encoding.  The "r" mnemonic is because this is a
"vaRiable" length encoding scheme.

LEB128 is used in various formats including DWARF, WebAssembly, MQTT,
and Protobuf.

[Feature #21785]
@pull pull bot locked and limited conversation to collaborators Dec 19, 2025
@pull pull bot added the ⤵️ pull label Dec 19, 2025
@pull pull bot merged commit 0c4fcdf into turkdevops:master Dec 19, 2025
1 of 2 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.

5 participants