RFR 8005698 : Handle Frequent HashMap Collisions with Balanced Trees

Brent Christian brent.christian at oracle.com
Fri May 31 18:27:35 UTC 2013

On 5/31/13 7:10 AM, Alan Bateman wrote:
> I've read through the latest webrev, overall very good work.
> I had to read splitTreeBin a few times to convince myself as to how the
> keys re-hash. I wonder if would be helpful to beef up the comment on
> this method.

I think that's a good idea:

--- 342,355 ----
int loCount = 0, hiCount = 0;
TreeNode<K,V> e = oldTree.first;
TreeNode<K,V> next;
! // This method is called when the table has just increased capacity,
! // so indexFor() is now taking one additional bit of hash into
! // account ("bit"). Entries in this TreeBin now belong in one of
! // two bins, "i" or "i+bit", depending on if the new top bit of the
! // hash is set. The trees for the two bins are loTree and hiTree.
! // If either tree ends up containing fewer than TREE_THRESHOLD
! // entries, it is converted back to a linked list.
while (e != null) {

> Otherwise I didn't see anything obviously wrong. Minor alignment issue
> with the comments on Holder.

Fixed, thanks.


More information about the core-libs-dev mailing list