Implement hash cache to fix #5280 #5289
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 #5280 travis-ci/travis-ci#9994
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 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 ?