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

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