| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/ruby/mmtk/commit/ed9036c295
|
|
https://github.com/ruby/mmtk/commit/4e789e118b
|
|
|
|
|
|
The cc_entries list associated with the invalidated CME can be deleted
from the table during GC, so it isn't safe to copy (and we shouldn't
copy it anyways, it's stale data).
|
|
fragile
|
|
|
|
|
|
Previously, calling IO#flush or closing an IO with unflushed buffered
writes would just invoke `#blocking_operation_wait` and flush the write
buffer using a `write` syscall. This change adds flushing through the
fiber scheduler by invoking the `#io_write` hook.
* Prefer IO::Buffer#write in IOScheduler
* Use Dir.tmpdir for test file
* Correctly handle errors in io_flush_buffer_fiber_scheduler
|
|
|
|
|
|
It seems hunging up.
|
|
|
|
This change fixes a bug in which specifying 0 for timeout-related options (such as the `timeout` option of `Addrinfo.getaddrinfo`) incorrectly results in an infinite wait.
(This change overwrites https://github.com/ruby/ruby/pull/15626 .)
|
|
Semicolon is optional however it clarifies the end of the rule.
|
|
|
|
A placeholder to handle GNU make jobserver option.
spec/default.mspec didn't handle the jobserver using a FIFO.
|
|
|
|
|
|
|
|
* Fix rbs test failure caused by minitest6
* Bundle minitest-6.0.0
|
|
|
|
|
|
https://github.com/ruby/prism/commit/21c499d6e4
|
|
Redo of https://github.com/ruby/prism/pull/3669 with more tests
https://github.com/ruby/prism/commit/48b403ea79
|
|
https://github.com/ruby/prism/commit/138db9ccc4
|
|
* assert_raise's 2nd argument is the failure message,
shown when the expected exception is not raised.
It's not the expected message.
See https://github.com/test-unit/test-unit/issues/347
https://github.com/ruby/prism/commit/e3df994d47
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>
|
|
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: Luke Gruber <luke.gru@gmail.com>
|
|
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.
|
|
* Ractor.yield no longer exists
* Ractor.shareable_proc returns a copy of the given proc
* Improve wording for monitoring/unmonitoring ports
|
|
[Bug #21793]
To fix a naming conflict on solaris.
|
|
Allows to remove some duplicated code like szqueue_length, etc.
|
|
If the queue was allocated without calling initialize,
`ary` will be `0`.
|
|
We receive the ec as argument, it's much cheaper to pass it
around that to look it up again.
|
|
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.
|
|
We never need the actual thread object and this avoid any issue
if the thread object is ever moved.
|
|
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.
|
