Sometimes `Leaked thread: Rinda::TestRingServer#test_ring_server_ipv6_multicast` happens
because `Rinda::TupleSpace#start_keeper` runs after stopping `@keeper`.
On ar_table, Do not keep a full-length hash value (FLHV, 8 bytes)
but keep a 1 byte hint from a FLHV (lowest byte of FLHV).
An ar_table only contains at least 8 entries, so hints consumes
8 bytes at most. We can store hints in RHash::ar_hint.
On 32bit CPU, we use 4 entries ar_table.
The advantages:
* We don't need to keep FLHV so ar_table only consumes
16 bytes (VALUEs of key and value) * 8 entries = 128 bytes.
* We don't need to scan ar_table, but only need to check hints
in many cases. Especially we don't need to access ar_table
if there is no match entries (in many cases).
It will increase memory cache locality.
The disadvantages:
* This technique can increase `#eql?` time because hints can
conflicts (in theory, it conflicts once in 256 times).
It can introduce incompatibility if there is a object x where
x.eql? returns true even if hash values are different.
I believe we don't need to care such irregular case.
* We need to re-calculate FLHV if we need to switch from ar_table
to st_table (e.g. exceeds 8 entries).
It also can introduce incompatibility, on mutating key objects.
I believe we don't need to care such irregular case too.
Add new debug counters to measure the performance:
* artable_hint_hit - hint is matched and eql?#=>true
* artable_hint_miss - hint is not matched but eql?#=>false
* artable_hint_notfound - lookup counts
iter_lev is used to detect the hash is iterating or not.
Usually, iter_lev should be very small number (1 or 2) so
`int` is overkill.
This patch introduce iter_lev in flags (7 bits, FL13 to FL19)
and if iter_lev exceeds this range, save it in hidden attribute.
We can get 1 word in RHash.
We can't modify frozen objects. Therefore I added new internal API
`rb_ivar_set_internal()` which allows us to set an attribute
even if the target object is frozen
if the name is hidden ivar (the name without `@` prefix).
This was never the right place. The method got there just by evolution,
not by design. Move it within default methods, where it suits better.
Since this method is presumably used just internally, it should be safe
to deprecate it and remove later.
https://github.com/rubygems/rubygems/commit/0c0dd9458a
Separate #add_runtime_dependency and #add_development_dependency
availability condition from #specification_version availability,
which is not related to directly.
Also check if the former method is available, instead of comparing
the version.
https://github.com/rubygems/rubygems/commit/5cccc2b836
Koichi Sasada
Aaron Patterson
git
Nobuyoshi Nakada
Yusuke Endoh
Benoit Daloze
Kazuhiro NISHIYAMA
Koichi Sasada
Hiroshi SHIBATA
bronzdoc
David Rodríguez
Vít Ondruch
Alexander Pakulov