Why does Java have such a large footprint?

Question

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.

• 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 much the JVM's footprint has changed?

Incorporation

You should post links to wherever you got your information from that the HotSpot VM "... has long had a reputation for having a very large memory footprint". – Lydgate

That "reputation" is really nothing more than a legacy from the Java 1.1 and 1.2 days when Java was young. – Atiptoe

I don't think that's entirely fair - Java certainly hasn't grown any smaller since then, we just typically have a lot more RAM to play with. Clearly the size of the runtime is hurting some people, o/w the Jigsaw project might not exist. – Lydgate

I was a bit skeptical, so I tried running "HelloWorld" in Java and C# (running on mono), both on Linux just to get an idea of the base footprint. For Java, (VSZ, RSS) = (261468, 9412), for C#+mono = (15536, 4840). That the Java virtual set size is more than an order of magnitude larger was surprising to me. – Snuffy

Do you care how big the VSZ size is?? – Wicketkeeper

On my Ubuntu 9.04, Hotspot takes 860MB of virtual memory, whereas Mono takes 43MB. But also the launching of many a Java app is a very noticeably sluggish experience. – Incorporation

Nowaday, GraalVM and its native image option may help reducing java application memory footpring. – Bornie

Answer 1

Some initiatives:

• Since 1.5 class data sharing can be used;
• Java 6 update 14 brought in compressed oops which reduces the footprint of 64-bit JVMs with under 4GB of Heap.

Halfbaked

Answer 2

We have some server-side apps which do nothing but bridge multicast traffic (i.e. they have no permanent state). They all run with about 2.3 - 2.5 Mb of Heap on a 32-bit Java6 (linux) JRE.

Is this a big footprint? I could easily have a thousand of these on a typical server-class machine (from a memory perspective), although that would be bit pointless from a threading perspective!

That said, there is the Jigsaw project to modularize the VM (the libraries I believe) which is coming in Java7; this will help those who wish for smaller footprints.

I realize that this doesn't really answer your question but it is relevant nonetheless! What sort of applications are you designing where you are finding that memory footprint is an issue?

Lydgate

Well, I have one Java application (NetBeans) running now, and java.exe uses 230 MB memory at the very moment. I wouldn't call it a small footprint. – Louls

That's nothing to do with the footprint of Java and everything to do with the NetBeans application! My IntelliJ IDEA frequently uses 700+ Mb of heap - that is because I have multiple projects open and it has indexed everything in memory for speed – Lydgate

Imho 230 MB for such IDE is small. Memory is cheap now anyway. – Bullet

For comparison, I have Google Chrome with 15+ tabs open, and it takes less than 50 MB. Java apps frequently use much more memory than their native counterparts. Whether it matters in practice or not, is a different question. – Louls

I have Chrome open with 12 tabs and it's using >250Mb. I'm sure this has a lot to do with what sites I'm visiting (pfffft): the same holds for Java apps. If they are caching lots of data internally then they are larger. This is nothing to do with the VM footprint – Lydgate

oxbow_lakes, my question pertains to the footprint of the VM itself, not just to the application heap size. If you were in fact claiming that the VM's entire Linux process takes less than 3 MB of resident memory, how did you achieve this feat? What specific configurations or flags did you use? Bear in mind, also, that I am mostly interested in an explanation and breakdown of the footprint, esp. of the footprint associated with a default (out-of-the-box) VM configuration. – Incorporation

This is very true. Using top -bp, the RES of the app is 17Mb. is this the footprint? It's actually not that obvious to me how to definitevely measure this – Lydgate

Answer 3

At least one thing is Java's long history - it started in 1995 and is now version 6. Keeping backwards compatibility while adding features inevitably inflates its footprint. The image below tells pretty much...

Louls

I think you might find that a little misleading. – Wicketkeeper

Let's say the runtime has increased in size by a factor of 7 in 12 years. The average RAM of a PC has gone up in the same time from around ~100Mb to ~2Gb; a factor of 20. Which means that in real terms the JDK has shrunk by a factor of 3. – Lydgate

If you were to look at the size of the English download bundles you may see a different picture. It's not so much keeping features that makes it big, as adding new ones. – Wicketkeeper

Maybe it has shrunk relatively, but compared to i.e. .NET (or Mono) runtimes it's still huge - in absolute or relative terms, whichever you prefer. – Louls

I don't any much experience with .Net or mono but I would guess that the difference can entirely be explained by the feature set offered by the JDK (CORBA, RMI, XML, HttpServer, JavaDB, javax.security etc) – Lydgate

I think most of the difference with .NET is down to .NET appearing as part of the OS. – Wicketkeeper

Yes, the difference can be explained with wider set of features - that's what I wrote. – Louls