Why does Java have such a large footprint?

Question

I've been curious about this topic for a while, but I haven't ever looked into this to any depth. I also posted this to stackoverflow but haven't gotten any solid responses so far:
http://stackoverflow.com/questions/1107991/why-does-java-have-such-a-large-footprint
Java - or at least Sun's Hotspot JVM - has long had a reputation for having a very large memory footprint. What exactly is it about the JVM that gives it this reputation? I'd be interested in a detailed breakdown: how much memory goes to the runtime? (The JIT? The GC/memory management? The classloader?) Anything related to "auxiliary" APIs like JNI/JVMTI? The standard libraries? (Which parts get how much?) Any other major components?
I realize that this may not be straightforward to answer without a concrete application plus VM configuration, so just to narrow things down at least somewhat: I'm primarily interested in default/typical VM configurations, and in a baseline console "Hello world" app as well as any real-world desktop or server app. (I'm suspecting that a substantial part of the JVM's footprint is largely independent of the app itself, and it is in this part that I'd like to zoom in, ideally.)
I have a couple of other closely related questions:
Other similar technology, such as .NET/mono, don't exhibit nearly the same footprint. Why is this the case?
I've read somewhere on the intarwebs that a large portion of the footprint is due simply to the size of the standard libraries. If this is the case, then why is so much of the standard libraries being loaded up front?
Are there any efforts (JSRs, whatever) to tame the memory footprint? The closest thing I've come across is a project to reduce the on-disk footprint of the JVM [1] and to modularize the standard library [2].
I'm sure that the footprint has varied over the past decade or so with every new version of Java. Are there any specific numbers/charts chronicling precisely how the JVM's footprint has changed?
[1] http://blogs.sun.com/jtc/entry/reduced_footprint_java_se_bringing
[2] http://blogs.sun.com/theplanetarium/entry/project_jigsaw_modularizing_jdk_7

Answer 1

yangzhang wrote:
I've been curious about this topic for a while, but I haven't ever looked into this to any depth. I also posted this to stackoverflow but haven't gotten any solid responses so far:
http://stackoverflow.com/questions/1107991/why-does-java-have-such-a-large-footprint
Java - or at least Sun's Hotspot JVM - has long had a reputation for having a very large memory footprint. What exactly is it about the JVM that gives it this reputation? I'd be interested in a detailed breakdown: how much memory goes to the runtime? (The JIT? The GC/memory management? The classloader?) Anything related to "auxiliary" APIs like JNI/JVMTI? The standard libraries? (Which parts get how much?) Any other major components?
Presumably versus some other VM. I would suppose the fact that much of the VM is written in java has something to do with it.
I realize that this may not be straightforward to answer without a concrete application plus VM configuration, so just to narrow things down at least somewhat: I'm primarily interested in default/typical VM configurations, and in a baseline console "Hello world" app as well as any real-world desktop or server app. (I'm suspecting that a substantial part of the JVM's footprint is largely independent of the app itself, and it is in this part that I'd like to zoom in, ideally.)
I have a couple of other closely related questions:
Other similar technology, such as .NET/mono, don't exhibit nearly the same footprint. Why is this the case?
Not sure I agree with that. What size do you see with a .Net app that uses 3.0/3.5?
I've read somewhere on the intarwebs that a large portion of the footprint is due simply to the size of the standard libraries. If this is the case, then why is so much of the standard libraries being loaded up front?
Good question. There is a feature that allows multiple VMs to use the same memory footprint version of the loaded libraries. That is a new feature and it isn't clear to me if it covers the entire API. I do not know if that is dynamically built.