The concurrent set, managed id-table dups and symbol id-entry buckets are
reachable from every Ractor via VM-global state (the frozen-string/symbol
tables, shape-tree edge tables, the symbol table), so flag them shareable --
as enc_list_update already does for the encoding list.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Set RUBY_TYPED_THREAD_SAFE_FREE on TypedData types whose dfree function
is trivially safe, and only frees its own memory
Types not yet marked as THREAD_SAFE_FREE:
- id2ref_tbl_type: sets the process-global id2ref_tbl to NULL.
- mutex_data_type: unlinks itself from another thread's keeping_mutexes list.
- autoload_data_type: deletes nodes from a shared intrusive list.
- autoload_const_type: deletes itself from a shared list.
- rb_cont_data_type: mutates the shared fiber pool and the global first_jit_cont list.
- rb_fiber_data_type: delegates to cont_free.
- FiberPoolDataType: mutates shared fiber pool free-lists.
- ractor_data_type: reconfigures global VM event-hook flags and call caches.
- exported_object_registry: frees a global table under the VM lock.
- rb_box_data_type (Box::Entry): unlinks classext from other live class and module objects.
- box_ext_cleanup_type: dereferences another String object and calls unlink.
- monitor_data_type: uses the default free, so the flag has no effect.
Co-authored-by: Luke Gruber <luke.gruber@shopify.com>
When CASing the garbage key to EMPTY, if we succeed we should decrease
set->size because we're trying to re-insert into the same slot right after.
The insertion increases set->size if it succeeds. This issue can lead to
set->size being overcounted, which can lead to more table resizes.
This removes all allocations from the find_or_insert loop, which
requires us to start the search over after calling the provided create
function.
In exchange that allows us to assume that all concurrent threads insert
will get the same view of the GC state, and so should all be attempting
to clear and reuse a slot containing a garbage object.
This refactors the concurrent set to examine and reserve a slot via CAS
with the hash, before then doing the same with the key.
This allows us to use an extra bit from the hash as a "continuation bit"
which marks whether we have ever probed past this key while inserting.
When that bit isn't set on deletion we can clear the field instead of
placing a tombstone.
Before, the 50% load factor was not working correctly with the new capacity
calculation on resize and too many resizes were seen.
Before this change
------------------
Example:
old_capacity = 32
old_size = 16
deleted_entries = 2 (almost all live)
That means we have:
expected_size = 14
We'll see that 64 > 14 * 4
We'll end up using 32 as the new capacity (same as old) even though that only
leaves us two elements free before we'd have to rebuild again.
Co-authored-by: John Hawthorn <john.hawthorn@shopify.com>
The atomic load/store operations here should mostly be using
release/acquire semantics. This may lead to better performance than what
we had under the default seq_cst.
On x86 this may make the atomic store of hash faster, as it can avoid
xchg. On ARM the loads may be faster (depending on target CPU for the
compiler).
Reference for comparison of atomic operations
https://godbolt.org/z/6EdaMa5rG
Previously we just had a comment stating that the code required a
barrier. Turns out it's not too difficult to properly assert that.
Co-authored-by: Luke Gruber <luke.gru@gmail.com>
When testing we've found that the concurrent_set objects used for
fstrings can grow quite large, and because they reach oldgen quickly end
up not being collected.
This commit is a bit of a hack but aims to improve that by moving the
objects to not be WB_PROTECTED. "Unprotected" objects do not age and
can't become oldgen, so this allows them to be collected in a minor GC.
If we create a key but don't insert it (due to other Ractor winning the
race), then it would leak memory if we don't free it. This introduces a
new function to free that memory for this case.
Since we resize when `prev_size > set->capacity / 2`, it's possible that
`prev_size == set->capacity / 2`, so we need to change the assertion in
concurrent_set_try_resize_without_locking to be
`new_set->size <= new_set->capacity / 2`.
