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

[Ivan Gerasimov]

Thanks for suggestion Jeff!

I've tried it, but it doesn't seem to make a difference on my machine.
Here are the numbers. I measured the time of a single put in nanoseconds.


----------- | vanila | fix1  | fix2
client      | 8292   | 8220  | 8304
server      | 8197   | 8198  | 8221
interpreter | 13980  | 14478 | 14152


fix1 - the fix from webrev #3
fix2 - the fix with your suggestion

Sincerely yours,
Ivan


On 06.07.2014 15:13, Jeff Hain wrote:
>
>
> >So, I reverted this change to the original code, but added a single
> >check of the current table size before doing any modifications to the 
> map.
> >This is to address the issue #4, and this doesn't seem to introduce any
> >significant penalty.
> >
> >Would you please help review the updated webrev:
> >
> >http://cr.openjdk.java.net/~igerasim/6904367/3/webrev/ 
> <http://cr.openjdk.java.net/%7Eigerasim/6904367/3/webrev/>
> >
> >Sincerely yours,
> >
> >Ivan
>
> It's possible to avoid the capacity test for the general case:
> put {
>     ...while loop...
>
>     if (size < threshold) {
>         modCount++;
>         tab[i] = k;
>         tab[i + 1] = value;
>         ++size;
>     } else {
>         putAndResize(k, value, i);
>     }
>     return null;
> }
> private void putAndResize(Object k, Object value, int i) {
>     if (size == MAXIMUM_CAPACITY - 1)
>         throw new IllegalStateException("Capacity exhausted.");
>     modCount++;
>     Object[] tab = table;
>     tab[i] = k;
>     tab[i + 1] = value;
>     ++size;
>     resize(tab.length); // len == 2 * current capacity.
> }
>
> It seems faster more often than not, but it adds more (and copied) code:
> not sure it's worth it.
>
> -Jeff
>
>