Looking at the source, it looks like HashMap needs about 16 + 4 *
(loadfactor) bytes per entry, plus a few bytes. Each bucket has four
fields, each field using four bytes. The pointer to the bucket is also
necessary, and since it's hashed, there are more bucket pointers than
actual buckets. This really isn't very many, and is probably dwarfed
by the memory need for the items being stored. (IE, a simple string
can use hundreds of bytes.)
In any case, the upper limit for a hash table is the JVM memory
allocation, so even gargantuan hash maps shouldn't be a problem. And
the great thing about hash maps is, even if they are gargantuan (ie,
millions of entries), the access time is still very fast.
Walter Gildersleeve
Freiburg, Germany
____________________________________________________
http://linkfrog.net
URL Shortening
Free and easy, small and green.
Thomas Hawtin - 24 Nov 2005 14:35 GMT
> Looking at the source, it looks like HashMap needs about 16 + 4 *
> (loadfactor) bytes per entry, plus a few bytes. Each bucket has four
[quoted text clipped - 3 lines]
> by the memory need for the items being stored. (IE, a simple string
> can use hundreds of bytes.)
It uses a bit more memory than this. Each object has (typically) a
pointer to the class information, a hash code and bits for use in
synchronisation and for garbage collection. Also on 64-bit systems, the
reference size will be doubled.
You could write a hash map with the entries inlined into the main array,
but it would tend to make any operation using Map.Entry slow.
The map may be many-to-one and the key may be shared or small, so memory
may be an issue in some obscure cases. A more likely (but still
unlikely) problem is GC pauses, particular if entries are medium lived.
> In any case, the upper limit for a hash table is the JVM memory
> allocation, so even gargantuan hash maps shouldn't be a problem. And
> the great thing about hash maps is, even if they are gargantuan (ie,
> millions of entries), the access time is still very fast.
Yup, because the table grows, the number of entries necessary to sort
through on every access remains very small.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/