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

[Peter Levart]

On 07/09/2014 02:46 AM, Martin Buchholz wrote:
> Let me understand - you're worried that when size is MAX_CAPACITY - 1, 
> then a call to putAll that does not actually add any elements might 
> throw?

This is not possible, because resize() is only called from putAll(map) 
if argument map.size() > this.size. At least one element will be added 
to the map and it's correct to throw if current size == MAX_CAPACITY - 1.

>  Well, I'm having a hard time considering that corner case a bug, 
> given how unusable the map is at this point.

It seems even this corner case is not present.

>
> Your suggested fix of returning immediately in case of no resize would 
> cause put to succeed and reach size == MAX_CAPACITY, which you were 
> trying to prevent.

That's not possible either, since resize() is always called from put() 
with current table.length, which makes newLength == 2 * oldLength, 
therefore (oldLength >= newLength) will never succeed in this case.

Peter

>
>
> On Tue, Jul 8, 2014 at 5:25 PM, Ivan Gerasimov 
> <ivan.gerasimov at oracle.com <mailto:ivan.gerasimov at oracle.com>> wrote:
>
>
>     On 09.07.2014 3:20, Martin Buchholz wrote:
>>     I agree with Peter that we do not need to increment modCount on
>>     resize.
>>
>>     My latest webrev is again "done".
>>
>>     Ivan, feel free to take over.
>
>     Yes, thanks! The fix is much much better now.
>
>     I think I see yet another very minor glitch, though.
>     If the table is already of size 2 * MAXIMUM_CAPACITY, and we're
>     merging in another map, which has more elements with putAll(),
>     resize() will be called and it will throw, even though all the
>     elements could fit into the map due to the key duplicates.
>
>     To avoid this the following check should be done first in resize():
>
>       469         if (oldLength >= newLength)
>       470             return false;
>       
>
>     Sincerely yours,
>     Ivan
>
>