Re: Memory utilization
On Jan 30, 3:20 pm, Lew <l...@lewscanon.com> wrote:
String has an OVERHEAD of 40bytes (AFAIK)
I'm not sure that's correct. Are you sure it isn't 4 bytes per String? 40
seems ridiculously high. Where'd you get that number?
Might be high, but doesn't seem ridiculous. A String
instance has its object-ness plus three ints and a char
reference. The char will have its own object-ness plus
a length. If object-ness takes eight bytes and a reference
takes four (32-bit JVM), we're up to at least 36 bytes. If
there's an eight-byte alignment requirement, 40 bytes is
right on the money.
On the machine you are on is it possible to increase your max heap
space higher? If so problem solved!
He's trying to create 2G pairs of String objects (72-80
bytes of overhead per pair) plus 2G HashMap.Entry objects
(~24 bytes each, under the same set of assumptions), hence
about 192-208GB -- and that's not counting the "payload" of
the char values, which will add another 80GB or thereabouts.
272GB is well beyond what a 32-bit JVM can manage, so he'll
need to go to a 64-bit version -- and this will expand the
String overhead to at least 40 bytes, and the HashMap.Entry
size to at least 36-40, raising the total to about 312-320GB.
And that's just for this one data structure; the rest of the
Java environment needs some heap, too. I'd guess that a
machine with half a terabyte of RAM could just about manage
it, with luck and a following wind.
... but in truth he's not really trying to populate this
enormous and pointlessly wasteful data structure; he's trying
to understand how the NetBeans profiler reports the memory
used by the program, and I'm afraid I can't help much with
that. After 4M pairs he sees
String -- 48MB
char -- 48 MB
HeapCharBuffer -- 45MB
Integer -- 19MB
HashMap$Entry -- 19MB
.... which works out to 6 bytes per string, 6 bytes per char,
and <5 bytes per HashMap.Entry -- clearly, the profiler reports
some other notion of "memory used" than we've been talking
about in the last few messages. All I can suggest is RTFM.