tree 7b5d9de116b21b9cc4a5f732531604843b23ad9e
parent 2ff89341f643920f827e4c45db8e4b507fedd9f0
author Michael Anthony Knyszek <mknyszek@google.com> 1713501661 +0000
committer Gopher Robot <gobot@golang.org> 1713547007 +0000

internal/concurrent: handle boundary case for hash bits in HashTrieMap

Currently the HashTrieMap has a panic for running out of hash bits, but
it turns out we can end up in these paths in valid cases, like inserting
or deleting an element that requires *all* the hash bits to finds its
position in the tree. There's basically an off-by-one error here where
the panic fires erroneously.

This wasn't caught before the original CL landed because it's very
unlikely on 64-bit platforms, with a 64-bit hash, but much more likely
on 32-bit platforms, where using all 32 bits of a 32-bit hash is much
more likely.

This CL makes the condition for panicking much more explicit, which
avoids the off-by-one error.

After this CL, I can't get the tests to fail on 32-bit under stress
testing.

Change-Id: I855e301e3b3893e2b6b017f6dd9f3d83a94a558d
Reviewed-on: https://go-review.googlesource.com/c/go/+/580138
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: David Chase <drchase@google.com>