chashmap merge requestshttps://gitlab.redox-os.org/redox-os/chashmap/-/merge_requests2021-01-13T06:03:06Zhttps://gitlab.redox-os.org/redox-os/chashmap/-/merge_requests/9Add with_hasher type of function2021-01-13T06:03:06ZFlyingCanoeAdd with_hasher type of functionThis PR add the `with_hasher` and `with_hasher_and_capacity` function which work much like their counterparts from the standard library.
However, for most operations, it requires the `BuildHasher` to implement `Default`. in practice thi...This PR add the `with_hasher` and `with_hasher_and_capacity` function which work much like their counterparts from the standard library.
However, for most operations, it requires the `BuildHasher` to implement `Default`. in practice this does not change much since all popular alternative implication of `BuildHasher` implement `Default`https://gitlab.redox-os.org/redox-os/chashmap/-/merge_requests/8Upgrade parking_lot to 0.112020-12-05T00:17:26ZKyle HueyUpgrade parking_lot to 0.11Tests pass locally.Tests pass locally.https://gitlab.redox-os.org/redox-os/chashmap/-/merge_requests/7Upgrade parking_lot to 0.10.2020-04-11T17:12:33ZKyle HueyUpgrade parking_lot to 0.10.https://gitlab.redox-os.org/redox-os/chashmap/-/merge_requests/6Fix panic after remove()2023-04-06T14:29:58ZAlex HornbyFix panic after remove()Fix panic after remove raised in https://gitlab.redox-os.org/redox-os/chashmap/issues/9
Reproduced issue by adding new tests, checked they failed
The underlying problem was lookup() and lookup_mut()'s handling of removed buckets, but ...Fix panic after remove raised in https://gitlab.redox-os.org/redox-os/chashmap/issues/9
Reproduced issue by adding new tests, checked they failed
The underlying problem was lookup() and lookup_mut()'s handling of removed buckets, but lookup_or_free() did the right thing.
With the test in place fixes were:
1. Generalized the old lookup_or_free to cover all lookup cases by parameterizing the lock->guard function.
2. Delete dead code no longer needed due to above
Tested using cargo test:
test result: ok. 34 passed; 0 failed; 0 ignored; 0 measured; 0 filtered outhttps://gitlab.redox-os.org/redox-os/chashmap/-/merge_requests/5Reduce growth factor from 4X to 2X. This saves a lot of memory, whilst reta...2023-04-06T14:29:56ZAlex HornbyReduce growth factor from 4X to 2X. This saves a lot of memory, whilst retaining amortized growthReduce growth factor set by LENGTH_MULTIPLIER from 4X to 2X. This saves a lot of memory for large maps, whilst retaining amortized growth when there are repeated inserts.
Tested with cargo testReduce growth factor set by LENGTH_MULTIPLIER from 4X to 2X. This saves a lot of memory for large maps, whilst retaining amortized growth when there are repeated inserts.
Tested with cargo testhttps://gitlab.redox-os.org/redox-os/chashmap/-/merge_requests/4implement fix and test for #92023-03-06T23:54:19Zicyimplement fix and test for #9Implement a (crude) fix for issue #9 as well as adding the given example code to the test suite.
This should be considered a preliminary PR and I recommend that improvements be made before merging. In particular, testing the bug again...Implement a (crude) fix for issue #9 as well as adding the given example code to the test suite.
This should be considered a preliminary PR and I recommend that improvements be made before merging. In particular, testing the bug against regressions requires adding a hash() method to the public API for CHashMap, which is suboptimal.
Also worth improvement is the logic used in scan_mut() and scan().
This code is not performance critical as it is only used in the (rare) case where the bug would be triggered. However, there is significant code duplication at the moment.https://gitlab.redox-os.org/redox-os/chashmap/-/merge_requests/3Fix for case where calling shrink_to_fit could make the map larger2020-01-20T17:52:37ZAlex HornbyFix for case where calling shrink_to_fit could make the map largerReproduced issue by adding new test shrink_to_fit_after_insert. Checked it was failing before doing any changes
With the test in place fixes were:
1. Make CHashMap::reserve be the place the amortizing growth factor LENGTH_MULTIPLIER i...Reproduced issue by adding new test shrink_to_fit_after_insert. Checked it was failing before doing any changes
With the test in place fixes were:
1. Make CHashMap::reserve be the place the amortizing growth factor LENGTH_MULTIPLIER is applied, rather than Table::with_capacity ( non-CHashMap::reserve users of Table::with_capacity are requesting a specific capacity and just need load factor applied, not amortizing growth multiplier )
2. Apply load factor consistently in Table::with_capacity() vs CHashMap::capacity()
3. Apply MINIMUM_CAPACITY in CHashMap::capacity to stop reported capacity being below requested.
4. Add test known_size_with_capacity_matches_shrink to test the initial capacity+shrink case
Tested via cargo testhttps://gitlab.redox-os.org/redox-os/chashmap/-/merge_requests/2Upgrade to latest version of parking_lot2020-01-20T17:53:00ZAlex GaynorUpgrade to latest version of parking_lothttps://gitlab.redox-os.org/redox-os/chashmap/-/merge_requests/1Updated dependencies2019-02-28T13:56:19ZSergey KletsunUpdated dependenciesJust updated dependencies to the recent ones. Tests are passed. Thanks!Just updated dependencies to the recent ones. Tests are passed. Thanks!