* `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.
This guard was removed in https://github.com/ruby/ruby/pull/13497
on the justification that some GC may need to be notified even for
immediate.
But the two currently available GCs don't, and there are plenty
of assumtions GCs don't everywhere, notably in YJIT and ZJIT.
This optimization is also not so micro (but not huge either).
I routinely see 1-2% wasted there on micro-benchmarks.
So perhaps if in the future we actually need this, it might make
sense to introduce a way for GCs to declare that as an option,
but in the meantime it's extra overhead with little gain.
The changes are to `io.c` and `thread.c`.
I changed the API of 2 exported thread functions from `internal/thread.h` that
didn't look like they had any use in C extensions:
* rb_thread_wait_for_single_fd
* rb_thread_io_wait
I didn't change the following exported internal function because it's
used in C extensions:
* rb_thread_fd_select
I added a comment to note that this function, although internal, is used
in C extensions.
Move these macros from include/ruby/backward.h to
include/ruby/internal/attr/deprecated.h, alongside the other similar
macros.
include/ruby/internal/intern/vm.h cannot currently use them because
include/ruby/backward.h is included too late.
`T_DATA` has a flag `RUBY_TYPED_FROZEN_SHAREABLE` which means
if the `T_DATA` object is frozen, it can be sharable.
On the `Ractor.make_sharable(obj)`, rechable objects from the
`T_DATA` object will be apply `Ractor.make_shareable` recursively.
`RUBY_TYPED_FROZEN_SHAREABLE_NO_REC` is similar to the
`RUBY_TYPED_FROZEN_SHAREABLE`, but doesn't apply `Ractor.make_sharable`
recursively for children.
If it refers to unshareable objects, it will simply raise an error.
I'm not sure this pattern is common or not, so it is not in public.
If we find more cases, we can discuss publication.
While profiling `Monitor#synchronize` and `Mutex#synchronize`
I noticed a fairly significant amount of time spent in
`rb_check_typeddata`.
By implementing a fast path that assumes the object is valid
and that can be inlined, it does make a significant difference:
Before:
```
Mutex 13.548M (± 3.6%) i/s (73.81 ns/i) - 68.566M in 5.067444
Monitor 10.497M (± 6.5%) i/s (95.27 ns/i) - 52.529M in 5.032698s
```
After:
```
Mutex 20.887M (± 0.3%) i/s (47.88 ns/i) - 106.021M in 5.075989s
Monitor 16.245M (±13.3%) i/s (61.56 ns/i) - 80.705M in 5.099680s
```
```ruby
require 'bundler/inline'
gemfile do
gem "benchmark-ips"
end
mutex = Mutex.new
require "monitor"
monitor = Monitor.new
Benchmark.ips do |x|
x.report("Mutex") { mutex.synchronize { } }
x.report("Monitor") { monitor.synchronize { } }
end
```
* `RB_OBJ_SET_SHAREABLE(obj)` makes obj shareable.
All of reachable objects from `obj` should be shareable.
* `RB_OBJ_SET_FROZEN_SHAREABLE(obj)` same as above
but freeze `obj` before making it shareable.
Also `rb_gc_verify_shareable(obj)` is introduced to check
the `obj` does not violate shareable rule (an shareable object
only refers shareable objects) strictly.
The rule has some exceptions (some shareable objects can refer to
unshareable objects, such as a Ractor object (which is a shareable
object) can refer to the Ractor local objects.
To handle such case, `check_shareable` flag is also introduced.
`STRICT_VERIFY_SHAREABLE` macro is also introduced to verify
the strict shareable rule at `SET_SHAREABLE`.
Ref: https://github.com/ruby/ruby/pull/14134#issuecomment-3207733725
We can't safely use low-bit pointer tagging anymore because `RTypedData.type`
lines up with `RData.dfree` and there is no aligment guarantee on function
pointers, as evidenced by `memcached` and `gpgme` gems.
We also can't use FL_USER* for this, because extensions may use these
for other purposes.
Using a general flag for this is a bit unfortunate, as general flags
are hard to come by, however I recently freed several of them, and
we still have two or three free ones left.
Also adds a static assertion to ensure the documented behavior stays
true, namely that the data field is at the same position in the RData
and RTypedData structs.
Similar to f3206cc79bec2fd852e81ec56de59f0a67ab32b7 but for TypedData.
It's quite common for TypedData objects to have a mix of reference in
their struct and some ivars.
Since we do happen to have 8B free in the RtypedData struct, we could
use it to keep a direct reference to the IMEMO/fields saving having
to synchronize the VM and lookup the `gen_fields_tbl` on every ivar
access.
For old school Data classes however, we don't have free space, but
this API is soft-deprecated and no longer very common.
This only adds the rbimpl_ version to include/ruby/atomic.h so that it
is not a new public interface.
We were already using RUBY_ATOMIC_VALUE_LOAD in a few locations. This
will allow us to use other memory orders internally when desired.
"store" is the terminology the C11 standard uses, which allows us to use
this as a fallback.
This only changes the private rbimpl_ version of the method,
RUBY_ATOMIC_SET et al. keep the same name.
* Add support for `cause:` argument to `Fiber#raise` and `Thread#raise`.
The implementation behaviour is consistent with `Kernel#raise` and
`Exception#initialize` methods, allowing the `cause:` argument to be
passed to `Fiber#raise` and `Thread#raise`. This change ensures that
the `cause:` argument is handled correctly, providing a more consistent
and expected behavior when raising exceptions in fibers and threads.
[Feature #21360]
* Shared specs for Fiber/Thread/Kernel raise.
---------
Co-authored-by: Samuel Williams <samuel.williams@shopify.com>
