RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size (original) (raw)

Ivan Gerasimov ivan.gerasimov at oracle.com
Tue Jul 8 01:54:12 UTC 2014

Thank you Martin for the enhancement!

It's a good idea to get rid of threshold variable! When the table grows large, it will start to try to resize the table on every single put(). Though it shouldn't matter much, as in such situation everything is already slow.

On 08.07.2014 4:44, Martin Buchholz wrote:

On Mon, Jul 7, 2014 at 9:41 AM, Martin Buchholz <martinrb at google.com_ _<mailto:martinrb at google.com>> wrote: I'd like to offer an alternative version of this change. webrev coming soon.

Here's the promised webrev. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/ <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/IdentityHashMap-capacity/> - Fixes a typo in the javadoc. - removes the "threshold" field (WAT, a cache to avoid multiplying by 3?) - optimizes 3*x into x + x << 1

Unfortunately, x + x << 1 causes the same overflow bug as 3*x: (int)(1431655766 + 1431655766 << 1) == 2

this can happen in capacity() and, theoretically, in putAll().

I propose to leave the check if (expectedMaxSize > MAXIMUM_CAPACITY / 3) return MAXIMUM_CAPACITY; which is overflow resistant.

In putAll, I guess, something like this can be used: int len = table.length; if (n > len || n > len - n || n > len - (n << 1)) resize(capacity(n));

- adds more test assertions - removes the unusual 4/3 slack space for expansion on deserialization. TODO: the test should be testng-ified, I think.

More information about the core-libs-dev mailing list