New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement hash cache to fix #5280 #5289
Conversation
To save memory we decided to not cache the hash value of the keys anymore when using open addressing as this was only necessary for a fast bucket skip when a bin collision happens. With the current approach, when a bin collision happens we call eql? on the keys. This was reasonable as this only happens when a collision occours. However, with this approach we always call eql? when a bin collision happens even when the hashes are different as we only use the lower bits of the hash to calculate the bin where the key / value pair is stored. This causes now that wrong implementation of eql? will crash always on a bin collisions and not only on a bin AND hash collision. As this is the case for bundler, there is no other way than caching the hash values again to reduce the probability that this happens. Fixes jruby#5280 travis-ci/travis-ci#9994
We only need to store the amount of expected pairs in the hashes entry and not the doubled size as we need in bins and entries.
because buckets is the actual size of the hash, so dividing is wrong and would create a too small hash (which then needs to get resized).
Ok, CI looks quite good 👍 |
@ChrisBr Hello! I beg to differ about the CI, because ruby/spec seem to get stuck after this change, see https://travis-ci.org/jruby/jruby/builds/419737258?utm_source=github_status&utm_medium=notification
Reverting this PR with:
Allows those specs to pass. |
@eregon hope you had safe travels back from EuRuKo! Thanks for the report, I will look into it |
@eregon I can not reproduce with on current master... But as this is related to Set, I could imagine that it might be related to as if the hash gets initialized with a non pow of two size, the secondary hash function is not a generator and therefore could end in an infinite loop. It could never reproduce this but it could be theoretically possible. Could you please try to reproduce with this PR: #5278 ? |
This will fix #5280 as we only use eql? now on a bin and hash collision. Before we didn't check the hash as we did not store it. This will restore similar behavior before the new hash implementation.