[RUN-1730] hashtable: make it ordered #616
Conversation
There was a problem hiding this comment.
I think, it would be better to either use CHECK_NE or we could create a new set of REPLAY_CHECK defines which simply point to their CHECK counterparts to avoid unnecessary code changes.
There was a problem hiding this comment.
Did you write this yourself?
Do you have a reference you can point to for this or can you explain it?
There was a problem hiding this comment.
Looks legit to me. It's a template method specialization on a templated class.
|
One more thing: Can you add linkage from https://linear.app/replay/issue/RUN-1730/make-all-chromium-hashset-and-hashmap-iteration-order-deterministic to here and vice versa?
|
kannanvijayan
left a comment
kannanvijayan
left a comment
There was a problem hiding this comment.
This looks reasonable overall, but I didn't rigorously check the logic or anything.
Only question I have is how this works during rehashing? Does it come automatically because the resized hashtable is inserted into using the existing routines, and those are already modified to build the ordering vectors?
There was a problem hiding this comment.
DCHECK compiles to no-op in our builds, so you may want to use something better for this if you want it to be actually checked.
There was a problem hiding this comment.
During rehashing, we build a new hash table, and then steal its guts, replacing the old table.
There's a comment in there that worries me, about how this works with the concurrent collector. I need to go find the code that scans the table, and make sure it only scans the table_ member before this can land.
There was a problem hiding this comment.
Please also see my other comment regarding DCHECK here
oridb
force-pushed
the
run1730-stable-hash-order
branch
from
6755139 to
e5de1a7
Compare
oridb
force-pushed
the
run1730-stable-hash-order
branch
from
182a3ce to
364ffb0
Compare
oridb
changed the title
kannanvijayan
left a comment
kannanvijayan
left a comment
There was a problem hiding this comment.
Looks good mostly. But see notes about using CHECK instead of DCHECK. It's probably good to fail fast more often just to be safe with this code at the start. I don't think the perf-impact of it would be huge.
There was a problem hiding this comment.
Looks legit to me. It's a template method specialization on a templated class.
| ValueType* old_table = table_; | ||
| unsigned old_table_size = table_size_; | ||
| auto old_table_size = table_size_; | ||
| //auto old_table_order = std::move(idxorder_); |
https://linear.app/replay/issue/RUN-1730/make-all-chromium-hashset-and-hashmap-iteration-order-deterministic