Only hash keys once#259
Conversation
3c0f7fa to
ccb03b0
Compare
|
Won't this break on resize AKA the reason the previous PR was reverted? |
|
Maybe I'm missing something, but I don't know how that would break. Can you point me to prior discussion? AFAICT the number of shards and the Hasher are fixed for the lifetime of the DashMap. Thus, the routing result should remain correct for the lifetime of DashMap and so is the hash passed down to the hashbrown shard. |
|
lgtm |
| let kptr: *const K = entry.key(); | ||
| let vptr: *mut V = entry.get_mut().as_ptr(); |
There was a problem hiding this comment.
I believe this violates stacked borrows, the entry.get_mut() invalidates the *const to the key. Inverting the order of the operations should be enough though.
|
👋 I'm not sure how exactly, but it looks like this change broke the crate download counting code on crates.io (see rust-lang/crates.io#7039). Admittedly, we are us the |
|
hm, interesting. I'll yank and revert for now. |
|
@Turbo87 Thanks for reporting. v5.5.2 is now out with this PR reverted. Since the earlier release has some other changes, would you guys mind updating to 5.5.2 and seeing if the issue is still resolved? |
|
This is quite surprising. Seems like some bad interaction with dashmap raw-api. |
yep, we'll try that. can't promise an exact timeframe yet, but we'll probably test it within the next couple of days. |
|
The problem seems to be that crates.io is replacing the Hashmaps shards yielded by the raw-api 😬 which in turn causes them to get a different hasher from Default::default. Specifically the I believe the issue would be prevented by replacing the hashmap with a new hashmap with the same hasher as before. This hasher can be acquired via |
just deployed with v5.5.3 and I can confirm that the issue is still resolved |
…w entry api (xacrimon#259)"" This reverts commit febc45d.
4 participants
Only hash keys once, by taking advantage of hashbrown raw entry api. This is roughly the same as #194.