* Add a "pinning" reference
A `Fiddle::Pinned` objects will prevent the objects they point to from
moving. This is useful in the case where you need to pass a reference
to a C extension that keeps the address in a global and needs the
address to be stable.
For example:
```ruby
class Foo
A = "hi" # this is an embedded string
some_c_function A # A might move!
end
```
If `A` moves, then the underlying string buffer may also move.
`Fiddle::Pinned` will prevent the object from moving:
```ruby
class Foo
A = "hi" # this is an embedded string
A_pinner = Fiddle::Pinned.new(A) # :nodoc:
some_c_function A # A can't move because of `Fiddle::Pinned`
end
```
This is a similar strategy to what Graal uses:
https://www.graalvm.org/sdk/javadoc/org/graalvm/nativeimage/PinnedObject.html#getObject--
* rename global to match exception name
* Introduce generic Fiddle::Error and rearrange error classes
Fiddle::Error is the generic exception base class for Fiddle exceptions.
This commit introduces the class and rearranges Fiddle exceptions to
inherit from it.
ac52d00223
Add rb_fiddle_ prefix to conversion functions.h to keep backward
compatibility but value_to_generic() isn't safe for TYPE_CONST_STRING
and not String src. Use rb_fiddle_value_to_generic() instead.
0ffcaa39e5
To make some kind of Ractor related extensions, some functions
should be exposed.
* include/ruby/thread_native.h
* rb_native_mutex_*
* rb_native_cond_*
* include/ruby/ractor.h
* RB_OBJ_SHAREABLE_P(obj)
* rb_ractor_shareable_p(obj)
* rb_ractor_std*()
* rb_cRactor
and rm ractor_pub.h
and rename srcdir/ractor.h to srcdir/ractor_core.h
(to avoid conflict with include/ruby/ractor.h)
The failure initially noticed on `autoconf-2.69d` (soon to become 2.70):
```
$ ./configure
./configure: line 8720: syntax error near unexpected token `fi'
./configure: line 8720: `fi'
```
Before the change generated `./configure ` snippet looked like:
```
if ! $CC -E -xc - <<SRC >/dev/null
then :
#if defined __APPLE_CC__ && defined __clang_major__ && __clang_major__ < 3
#error premature clang
#endif
SRC
as_fn_error $? "clang version 3.0 or later is required" "$LINENO" 5
fi
```
Note the newline that breaks here-document syntax.
After the change the snippet does not use here-document.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Allocating an instance of a class uses the allocator for the class. When
the class has no allocator set, Ruby looks for it in the super class
(see rb_get_alloc_func()).
It's uncommon for classes created from Ruby code to ever have an
allocator set, so it's common during the allocation process to search
all the way to BasicObject from the class with which the allocation is
being performed. This makes creating instances of classes that have
long ancestry chains more expensive than creating instances of classes
have that shorter ancestry chains.
Setting the allocator at class creation time removes the need to perform
a search for the alloctor during allocation.
This is a breaking change for C-extensions that assume that classes
created from Ruby code have no allocator set. Libraries that setup a
class hierarchy in Ruby code and then set the allocator on some parent
class, for example, can experience breakage. This seems like an unusual
use case and hopefully it is rare or non-existent in practice.
Rails has many classes that have upwards of 60 elements in the ancestry
chain and benchmark shows a significant improvement for allocating with
a class that includes 64 modules.
```
pre: ruby 3.0.0dev (2020-11-12T14:39:27Z master 6325866421)
post: ruby 3.0.0dev (2020-11-12T20:15:30Z cut-allocator-lookup)
Comparison:
allocate_8_deep
post: 10336985.6 i/s
pre: 8691873.1 i/s - 1.19x slower
allocate_32_deep
post: 10423181.2 i/s
pre: 6264879.1 i/s - 1.66x slower
allocate_64_deep
post: 10541851.2 i/s
pre: 4936321.5 i/s - 2.14x slower
allocate_128_deep
post: 10451505.0 i/s
pre: 3031313.5 i/s - 3.45x slower
```
Before this commit, `clone` gave different results depending on whether the original object
had an attached singleton class or not.
Consider the following setup:
```
class Foo; end
Foo.singleton_class.define_method(:foo) {}
obj = Foo.new
obj.singleton_class if $call_singleton
clone = obj.clone
```
When `$call_singleton = false`, neither `obj.singleton_class.singleton_class` nor
`clone.singleton_class.singleton_class` own any methods.
However, when `$call_singleton = true`, `clone.singleton_class.singleton_class` would own a copy of
`foo` from `Foo.singleton_class`, even though `obj.singleton_class.singleton_class` does not.
The latter case is unexpected and results in a visibly different clone, depending on if the original object
had an attached class or not.
Co-authored-by: Ufuk Kayserilioglu <ufuk.kayserilioglu@shopify.com>
If two or more tracepoints enabled with the same target and with
different target lines, the only last line is activated.
This patch fixes this issue by remaining existing trace instructions.
[Bug #17302]
