ruby.git - The Ruby Programming Language

path: root/spec/ruby/core/file/stat/grpowned_spec.rb

diff options

Diffstat (limited to 'spec/ruby/core/file/stat/grpowned_spec.rb')

0 files changed, 0 insertions, 0 deletions

521fe'>Use continuation bit in concurrent setJohn Hawthorn 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. 2025-12-09Fixed by `misspell -w -error -source=text`Hiroshi SHIBATA 2025-10-30Change load factor of concur. set from 0.5 to 0.75 (#15007)Luke Gruber 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> 2025-10-15Use explicit memory orders in concurrent_setJohn Hawthorn 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 2025-10-10Add ASSERT_vm_locking_with_barrierJohn Hawthorn 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> 2025-09-10Allow concurrent_set to be collected in minor GCJohn Hawthorn 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. 2025-07-22Fix missing increment of deleted_entriesKunshan Wang When `rb_concurrent_set_foreach_with_replace` deletes entries from a concurrent set, it should increment the `deleted_entries` field, too. 2025-07-21Don't rehash on retry in concurrent setPeter Zhu Since the hash should never change, we only need to calculate it once. 2025-07-21Introduce free function to rb_concurrent_set_funcsPeter Zhu 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. 2025-07-21Don't call cmp on garbage objectsPeter Zhu If the object is garbage, then calling cmp on it may crash. 2025-07-21Convert global symbol table to concurrent setPeter Zhu 2025-07-21Add rb_concurrent_set_findPeter Zhu 2025-07-21Add rb_concurrent_set_sizePeter Zhu 2025-07-21Skip garbage check for special consts in concurrent setPeter Zhu rb_objspace_garbage_object_p expects only GC managed objects to be passed in. We should skip the check if curr_key is a special constant. 2025-07-18Fix size assertion in concurrent set resizingPeter Zhu 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`. 2025-07-15Make rb_concurrent_set_funcs constPeter Zhu We should never modify rb_concurrent_set_funcs during runtime, so we can make it const. 2025-07-07Rename `ractor_safe_set` into `concurrent_set`Jean Boussier There's nothing ractor related in them, and the classic terminology for these sort of data structures is `concurrent-*`, e.g. concurrent hash.


context:
space:
mode: