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]
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
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>
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.
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.
`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
4fb537b1ee28bb37dbe551ac65c279d436c756bc.
Since singleton classes are created lazily, we need to make sure that
we lock around their creation. Unfortunately, that means we need to
lock around every shareable object's call to `singleton_class`,
including classes and modules.
This improves several enhancements to the Aliki theme. And since Aliki
also became the default theme, we don't need to specify the generator name
anymore.
* `rb_intern_str`: the argument must be `T_STRING`, no conversion.
* `rb_intern_str`, `rb_check_id`, `rb_to_id`, `rb_check_symbol`: raise
`EncodingError` unless the "name" argument is a valid string in its
encoding.
When a ractor was being initialized and it would join the heap dump barrier when
allocating its queue or its ports, the heap dump code calls `rb_obj_memsize` on
the ractor and this function assumed `ports` was never NULL. We need to check for
the NULL case in case the ractor is still being initialized. Hopefully other T_DATA
objects don't suffer from the same issue, otherwise we could revert the ractor barrier
during heap dump or not use `rb_obj_memsize` on T_DATA during the heap dump.
