Heap space occupied by the Java runtime itself

Question

I would like to solicit your inputs on the basic doubt i have on java heap space.

I would like to know the object allocated or the percentage of heap space or overall java memory space acquired by Java runtime itself.

Same question applies to the java servlet or Java EE containers like Tomcat or any other application servers.

I checked some basic heap dumps for tomcat when i run a bare minimal JSP page . I can see it already has taken 17 MB where i see some objects allocated for catalina class loader classes. I did the analysis using Eclipse Memory analyzer tool.

Same i see when i run standalone Java program which has some char[] loaded by the classloaders.

May be more objects will be allocated when i run more complex scenarios.

Can i somehow influence this basic loading of java runtime classes or object allocations using some VM arguments or by something else?

Answer 1

With Java 9 and Project Jigsaw the JVM was modularized and it's now possible to build a reduced JVM runtime. You can use jlink tool to build custom JRE with base Java modules and your code as shown in this tutorial .

As a side effect this cleaned up weird dependencies that evolved in the Java internal classes. This should lead to faster startup as fewer classes will be loaded during startup until you declare an import .

Answer 2

Look at the Runtime class. It provides some basic memory utilization numbers for the JRE.

As for memory utilization overall, Java tends to use a lot of memory. 17 MB is a small amount when running Tomcat. If you are running on a device with severe memory constraints, you could look for servers that are designed to have small footprints.

Answer 3

I can't really provide an answer (except for saying "NO"), but this is far too long for a comment.

Java is very memory hungry and 17 MB is something I just refuse to thing about. When your server gets some heavy traffic, then there may be hundreds requests in flight, each of them consuming maybe one megabyte for the thread stack and possibly much more for its data. There will be caches consuming a good deal of remaining memory - no matter how much memory you have, you'll find a use for it.

This hunger is by design - a server is meant to be a big machine as a few gigabytes are much cheaper than a few days of work needed to save some memory. This doesn't imply sloppy design - on the opposite, there are countless optimizations put into every piece of software. It's just that they concentrate on speed and are tuned for big machines (eg, your JSP gets compiled into a Servler, which gets cached. That's surely better than re-generating it every time, isn't it?).

And then there's the GC, which further increases the needed memory. It's worth it, as it saves us days of hunting memory allocation bugs.

yes...exactly..what i have seen some severs reaching upto 500 MB where my heap space is 1.5 GB and overall RAM is 2GB...in this scenario my application has virtually 1GB which becomes very difficult to manage for us

My server for a startup uses 4 GB (out of 16 GB). It can currently run with much less, but we expect that much to be needed for full performance in maybe one year. There are servers using hundreds of gigabytes (and running into problems with very long GC pauses).

Instead of trying to minimize the memory usage, you could pack multiple servlets on a single Tomcat instance (assuming you need multiple servlets). Then you'd have to get bigger servers, but you can get more of each of them.