Age | Commit message (Collapse) | Author |
|
Notes:
Merged: https://github.com/ruby/ruby/pull/6721
|
|
The internal location in ractor.rb is not usefull at all.
```
$ ruby -e 'Ractor.new {}'
<internal:ractor>:267: warning: Ractor is experimental, ...
```
Notes:
Merged: https://github.com/ruby/ruby/pull/6629
Merged-By: nobu <nobu@ruby-lang.org>
|
|
Shapes provides us with an (almost) exact count of instance variables.
We only need to check for Qundef when an IV has been "undefined"
Prefer to use ROBJECT_IV_COUNT when iterating IVs
Notes:
Merged: https://github.com/ruby/ruby/pull/6555
|
|
Clang says "warning: variable 'pcnt' set but not used" here. In fact it
doesn't. The intention is clear that we want to increment cnt, not pcnt.
Adding a * mark solves everything.
Notes:
Merged: https://github.com/ruby/ruby/pull/6358
|
|
Ractor verification requires storing the ractor id in the top 32 bits of
the object header. Unfortunately 32 bit machines only have 32 bits in
the object header. The verification code has a 32 bit left shift which
doesn't work on i686 and will clobber existing flags.
This commit disables the verification code on i686 since i686 will crash
if it's enabled.
Co-Authored-By: John Hawthorn <john@hawthorn.email>
Co-Authored-By: Jemma Issroff <jemmaissroff@gmail.com>
Notes:
Merged: https://github.com/ruby/ruby/pull/6279
|
|
... as per ko1's request.
Notes:
Merged: https://github.com/ruby/ruby/pull/6169
|
|
[Misc #18891]
Notes:
Merged: https://github.com/ruby/ruby/pull/6094
|
|
Now GVL is not process *Global* so this patch try to use
another words.
* `rb_global_vm_lock_t` -> `struct rb_thread_sched`
* `gvl->owner` -> `sched->running`
* `gvl->waitq` -> `sched->readyq`
* `rb_gvl_init` -> `rb_thread_sched_init`
* `gvl_destroy` -> `rb_thread_sched_destroy`
* `gvl_acquire` -> `thread_sched_to_running` # waiting -> ready -> running
* `gvl_release` -> `thread_sched_to_waiting` # running -> waiting
* `gvl_yield` -> `thread_sched_yield`
* `GVL_UNLOCK_BEGIN` -> `THREAD_BLOCKING_BEGIN`
* `GVL_UNLOCK_END` -> `THREAD_BLOCKING_END`
* removed
* `rb_ractor_gvl`
* `rb_vm_gvl_destroy` (not used)
There are GVL functions such as `rb_thread_call_without_gvl()` yet
but I don't have good name to replace them. Maybe GVL stands for
"Greate Valuable Lock" or something like that.
Notes:
Merged: https://github.com/ruby/ruby/pull/5814
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5703
|
|
* Prefixed ccan headers
* Remove unprefixed names in ccan/build_assert
* Remove unprefixed names in ccan/check_type
* Remove unprefixed names in ccan/container_of
* Remove unprefixed names in ccan/list
Co-authored-by: Samuel Williams <samuel.williams@oriontransfer.co.nz>
Notes:
Merged-By: ioquatix <samuel@codeotaku.com>
|
|
I have this scripts that deadlocks after about
5 minutes if I repeatedly run it with a shell loop:
```ruby
$VERBOSE = nil
lamb = ->(main, gc) do
gc.verify_internal_consistency
gc.verify_internal_consistency
main << 1
gc.verify_internal_consistency
gc.verify_internal_consistency
main << 2
gc.verify_internal_consistency
gc.verify_internal_consistency
main << 3
gc.verify_internal_consistency
gc.verify_internal_consistency
end
lamb[[], GC]
lamb[[], GC]
r = Ractor.new Ractor.current, GC, &lamb
a = []
a << Ractor.receive_if{|msg| msg == 2}
a << Ractor.receive_if{|msg| msg == 3}
a << Ractor.receive_if{|msg| msg == 1}
```
Shell loop:
```shell
while ./miniruby deadlock.rb; do date; done
```
Once it locks up, CTRL-C doesn't interrupt the process which
led me to infer `receive_if` is looping in `ractor_receive_if()`
without checking for interrupts. This can be confirmed by
attaching a debugger to the deadlocked miniruby.
The deadlock has one thread looping in `receive_if`
and another waiting in `rb_vm_barrier()`. The barrier relies
on interrupt checking to finish. Theoretically speaking the
`rb_vm_barrier()` could come from one thread naturally starting GC.
We found this while developing YJIT but it dead locks running
with YJIT disabled. YJIT currently relies on `rb_vm_barrier()`
to synchronize before changing memory protection.
This diff adds an interrupt check in the loop in `Ractor#receive_if`
which seems to fix the deadlock.
In addition, this commit allows interrupting the following single
ractor script with CTRL-C.
```shell
ruby -e 'Ractor.current.send(3); Ractor.receive_if { false }'
```
Notes:
Merged: https://github.com/ruby/ruby/pull/5699
Merged-By: XrXr
|
|
`USE_RUBY_DEBUG_LOG` was only defined when `RUBY_DEVEL` is defined.
This patch removes this dependency (`USE_RUBY_DEBUG_LOG` is defined
independently from `RUBY_DEVEL`).
Do not commit a patch which enables `USE_RUBY_DEBUG_LOG`.
Notes:
Merged: https://github.com/ruby/ruby/pull/5366
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/5345
|
|
Renaming uJIT to YJIT. AKA s/ujit/yjit/g.
|
|
* ujit: implement opt_getinlinecache
Aggressively bet that writes to constants don't happen and invalidate
all opt_getinlinecache blocks on any and all constant writes.
Use alignment padding on block_t to track this assumption. No change to
sizeof(block_t).
* Fix compile warnings when not RUBY_DEBUG
* Fix reversed condition
* Switch to st_table to keep track of assumptions
Co-authored-by: Aaron Patterson <aaron.patterson@gmail.com>
Co-authored-by: Maxime Chevalier-Boisvert <maximechevalierb@gmail.com>
|
|
Probably `__func__` is supported since Visual C++ 2015 (= 14.0,
`_MSC_VER` = 1900).
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/4903
|
|
|
|
rb_objspace_reachable_objects_from requires that the GC not be active.
Since the Ractor barrier is not executed for incremental sweeping,
Ractor may call rb_objspace_reachable_objects_from after sweeping
has started to share objects. This causes a crash that looks like
the following:
```
<internal:ractor>:627: [BUG] rb_objspace_reachable_objects_from() is not supported while during_gc == true
```
Co-authored-by: Vinicius Stock <vinicius.stock@shopify.com>
Notes:
Merged: https://github.com/ruby/ruby/pull/4755
|
|
When a Ractor is removed, the freelist in the Ractor cache is not
returned to the GC, leaving the freelist permanently lost. This commit
recycles the freelist when the Ractor is destroyed, preventing a memory
leak from occurring.
Notes:
Merged: https://github.com/ruby/ruby/pull/4613
|
|
If the GC has been disabled we need to re-enable it so we can evacuate
the transient heap.
Fixes https://bugs.ruby-lang.org/issues/17985
[Bug #17985] [ruby-core:104260]
Co-authored-by: Aaron Patterson <tenderlove@ruby-lang.org>
Notes:
Merged: https://github.com/ruby/ruby/pull/4596
|
|
Notes:
Merged-By: k0kubun <takashikkbn@gmail.com>
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/4414
|
|
|
|
Defer making ractor stdio until ractor started.
Before ractor started, created objects belong to the caller ractor
instead of the created ractor.
Notes:
Merged: https://github.com/ruby/ruby/pull/4241
Merged-By: nobu <nobu@ruby-lang.org>
|
|
Ractor.allocate and Ractor#dup should not be allowed like Thread.
[Bug #17642]
Notes:
Merged: https://github.com/ruby/ruby/pull/4198
|
|
Ractor.yield(obj, move: true) and
Ractor.select(..., yield_value: obj, move: true) tried to yield a
value with move semantices, but if the trial is faild, the obj
should not become a moved object.
To keep this rule, `wait_moving` wait status is introduced.
New yield/take process:
(1) If a ractor tried to yield (move:true), make taking racotr's
wait status `wait_moving` and make a moved object by
`ractor_move(obj)` and wakeup taking ractor.
(2) If a ractor tried to take a message from a ractor waiting fo
yielding (move:true), wakeup the ractor and wait for (1).
Notes:
Merged: https://github.com/ruby/ruby/pull/4105
|
|
alen was number of rs, but it should be actions number
(taking ractors + receiving + yielding).
Notes:
Merged: https://github.com/ruby/ruby/pull/4105
|
|
Use ractor_wakeup() for same code.
|
|
expose some C-APIs to try to make ractor utilities on external gems.
* add
* rb_ractor_local_storage_value_lookup() to check availability
* expose
* rb_ractor_make_shareable()
* rb_ractor_make_shareable_copy()
* rb_proc_isolate() (not public)
* rb_proc_isolate_bang() (not public)
* rb_proc_ractor_make_shareable() (not public)
|
|
to reset main ractor at fork().
|
|
With locking a ractor, rb_ary_push() can call RB_VM_LOCK_ENTER()
and it violates an assertion: should not acquire ractor-lock.
|
|
* Fixed use of rb_ractor_shareable_p
* Raise Ractor::IsolationError
Notes:
Merged: https://github.com/ruby/ruby/pull/3950
|
|
When `literal`, check if the literal about to be assigned to a
constant is ractor-shareable, otherwise raise `Ractor::Error` at
runtime instead of `SyntaxError`.
Notes:
Merged: https://github.com/ruby/ruby/pull/3950
|
|
rb_warn can produce T_HASA object and it should not use
transient heap.
|
|
|
|
Notes:
Merged: https://github.com/ruby/ruby/pull/3960
|
|
This API is similar to plain old Thread#[]/Fiber#[] interface
with symbol key.
Notes:
Merged: https://github.com/ruby/ruby/pull/3962
|
|
separate some fields from rb_ractor_t to rb_ractor_pub and put it
at the beggining of rb_ractor_t and declare it in vm_core.h so
vm_core.h can access rb_ractor_pub fields.
Now rb_ec_ractor_hooks() is a complete inline function and no
MJIT related issue.
Notes:
Merged: https://github.com/ruby/ruby/pull/3943
|
|
TracePoint should be ractor-local because the Proc can violate the
Ractor-safe.
Notes:
Merged: https://github.com/ruby/ruby/pull/3943
|
|
Ractor has several restrictions to keep each ractor being isolated
and some operation such as `CONST="foo"` in non-main ractor raises
an exception. This kind of operation raises an error but there is
confusion (some code raises RuntimeError and some code raises
NameError).
To make clear we introduce Ractor::IsolationError which is raised
when the isolation between ractors is violated.
Notes:
Merged: https://github.com/ruby/ruby/pull/3957
|
|
Because unfreeze Ractor::MovedObject at
https://github.com/ruby/ruby/commit/76e88480371469400346fca609efe67096813915
|
|
It should raise an error if the same thread tris to call
receive/receive_if.
Notes:
Merged: https://github.com/ruby/ruby/pull/3949
|
|
from rb_ractor_make_copy_shareable().
|
|
To check shareable-ness, rb_ractor_shareable_p() is needed
for Class/Module objects isntead of checking flags.
|
|
|
|
Notes:
Merged-By: marcandre <github@marc-andre.ca>
|
|
Matz prefers to unfreeze the class.
[Feature #17401]
|