HashMap bug for large sizes
Eamonn McManus
eamonn at mcmanus.net
Fri Jun 1 20:05:04 UTC 2012
> But it is not just serializing a HashMap that does not work. HashMap.size()
> and HashMap.clear() isn't working as well.
I don't see what's wrong with HashMap.clear(), but HashMap.size() is
clearly buggy and should be fixed. There's also a performance problem
in that accesses start becoming linear once there are more than 1 <<
30 entries, but fixing that is substantially harder than just fixing
size(), and ConcurrentHashMap already provides a better alternative
for such huge maps.
Éamonn
On 1 June 2012 12:28, Kasper Nielsen <kasperni at gmail.com> wrote:
> On 01-06-2012 21:12, Eamonn McManus wrote:
>>
>> It seems to me that since the serialization of HashMaps with more than
>> Integer.MAX_VALUE entries produces an output that cannot be
>> deserialized, nobody can be using it, and we are free to change it.
>> For example we could say that if the read size is -1 then the next
>> item in the stream is a long that is the true size, and arrange for
>> that to be true in writeObject when there are more than
>> Integer.MAX_VALUE entries.
>
> Yeah,
> I thought of something along the lines of:
>
> long mapSize;
> s.writeInt(mapSize> Integer.MAX_VALUE ? Integer.MAX_VALUE : (int) mapSize );
> for (int i=0;i<Integer.MAX_VALUE;i++) {write elements}
>
> if (mapSize>=Integer.MAX_VALUE) {
> s.writeLong(size);//write the real size
> for (long i=Integer.MAX_VALUE;i<mapSize;i++) { ...write remaining elements
> }
>
> }
>
>> Whether there really are people who have HashMaps with billions of
>> entries that they want to serialize with Java serialization is another
>> question.
>
>
> But it is not just serializing a HashMap that does not work. HashMap.size()
> and HashMap.clear() isn't working as well.
>
> - Kasper
More information about the core-libs-dev
mailing list