RFR: [6904367]: (coll) IdentityHashMap is resized before exceeding the expected maximum size
Ivan Gerasimov
ivan.gerasimov at oracle.com
Thu Jul 3 19:38:03 UTC 2014
Thank you Jeff!
On 03.07.2014 23:07, Jeff Hain wrote:
>
> Hi.
>
>
> >WEBREV: http://cr.openjdk.java.net/~igerasim/6904367/0/webrev/
> <http://cr.openjdk.java.net/%7Eigerasim/6904367/0/webrev/>
>
> The "while" loop in put(...) supposes that there is at least one free
> slot,
> which was the case before (that could be added as comment).
>
> Now if you try to go past max capacity, instead of getting an
> IllegalStateException,
> you get an infinite loop.
>
Yes, you're right!
> It's easy to test with a loop of 1000 puts and MAX_CAPACITY = 1<<8
> (=256, needs to be larger than DEFAULT_CAPACITY, else it can be
> "ignored").
> With previous version you get IllegalStateException on trying to add
> 255th mapping
> (on the resize that occurs when just-after-put-size is 255 >=
> threshold = 255),
> and with new version you get infinite loop on trying to add 257th mapping.
>
> Solutions I see would be adding a throw if size >= MAX_CAPACITY
> before the loop,
>
This would break the case when an existing key is added to the already
full table.
Moreover, the full table without a single empty slot could cause an
infinite looping in get(), remove(), etc.
> or not adding that overhead and instead throwing when
> "size >= MAX_CAPACITY-1" instead of when "size >= MAX_CAPACITY".
>
This seems appropriate.
With the current implementation we can only put MAX_CAPACITY-1 elements
anyway.
> I would also rather use "==" over ">=" for these tests, to underline
> the fact
> that size is not supposed to be larger, but there might be some
> reasons not to.
>
I think it makes the code a bit more stable from the perspective of the
future changes.
Here's the updated webrev:
http://cr.openjdk.java.net/~igerasim/6904367/1/webrev/
Sincerely yours,
Ivan
>
> -Jeff
>
>
>
More information about the core-libs-dev
mailing list