The last time I paid attention to the Java vs Lisp vs C++ discussion, the shibboleth about JVM memory usage was that the JVM pre-allocated lots of memory to optimize for the case where the application was going to be big and long lived, at the cost of longer start up times and bad memory usage benchmarks for toy programs. I was under the impression that huge JVM footprints were mostly because of this pre-allocation behavior, not because the JVM itself uses lots of memory to maintain itself - am I wrong?
Both. JVM also allocates a lot of memory (relatively) for even its smallest objects (round sizes up, frequent boxing and copying of primitives, everybody gets an automatic mutex), and fragments significantly because it has good garbage collectors that deal fine with that.
A lot of Java is optimized for this, and it would take a fair bit of work to make a JVM (and compiler!) implementation that changed the behavior pervasively.
Java assumes memory is cheap at many levels. And usually, it's right.
"Java assumes memory is cheap at many levels. And usually, it's right."
I would say it's usually wrong. Imagine how much ram you'd need if all of your GUI apps were on the JVM. Imagine how much ram you'd need if '$ cat blah.txt | grep "something" | uniq | sort' were all JVM processes. Etc, etc, etc.
It seems to only be right for long lived server side processes that have enough load to make it a benefit.
You wouldn't architect that in that way in JVM. Instead, you'd use threads rather than processes, use heavier-weight but more capable tools and so on.
The JVM is not The Unix Way. You have to do things differently - and in Java-land, they do.
It's not really my thing either, but it's not as bad as you'd think if you just pretend we're mapping all our existing Unix stuff, unchanged, into Java.
Maintaining a garbage collector requires overhead, hence why C++ does not implement one as part of the language.
From my experience at University, the JVM uses an indirect method of accessing and storing objects. So each reference to an object is effectively a handle, hence as big as a pointer. It points to a table that contains the actual pointer to the object in memory (or something to that effect), so that the garbage collector can move the object in memory.
Therefore an object that just has a single integer will require 2 pointers and an integers worth of memory (at least). Any less than that and it would be garbage collected since there are no live references in the code to the object.
While that’s one way to do it, I believe that current JVMs use an index directly to the target object in the Java heap. Since the garbage collector is following all the references anyway, it can eventually update all the old references to point directly to an object after moving it.
In 64-bit VMs without a very large maximum heap size, the JVM usually uses "compressed" pointers, too, so 32-bit values can, in practice, address 32GB of data. Intel CPUs have addressing modes that work quite well with this. See: http://wikis.sun.com/display/HotSpotInternals/CompressedOops
Garbage collection isn’t free, but it’s getting pretty good.
I'm not sure where all the memory goes. My 'hello world' test app used around 30MB heap and 25+MB for permgen. It had a fair number of threads running, not sure what the overhead is there, but the process as a whole was using about 100MB. I couldn't make the heap any small without getting out of memory errors if I hit it with a light load.
edit: keep in mind this memory includes your app server, in my case I was using jetty.
Likely, most of those threads are HTTP request handlers. Try to let ab loose on your application and watch it's memory usage. I'm pretty sure you won't see any significant increase.
