HashMap bug for large sizes (original) (raw)

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.MAXVALUE 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.MAXVALUE entries. Yeah, I thought of something along the lines of: long mapSize; s.writeInt(mapSize> Integer.MAXVALUE ? Integer.MAXVALUE : (int) mapSize ); for (int i=0;i<Integer.MAXVALUE;i++) {write elements}_ _if (mapSize>=Integer.MAXVALUE) {  s.writeLong(size);//write the real size  for (long i=Integer.MAXVALUE;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