What is the memory footprint of the JVM and how can I minimize it?

Question

I just wanted to know what the actual footprint of the JavaVM (Sun, Linux) is when one starts to start to spawn multiple processes of JVMs. When I remember well those should share the rt.jar (and maybe beyond?). Does those JVM share the JIT cache (all JVM feature the same Classpath)?

Is there anything I can do to reduce the overhead of multi-instance JVM? (beside of setting smaller limits for the heap)?

Anything I can do while programming the application?

Can I share memory areas? Maybe share mapped memory blocks?

Apparitor

Why do you need to spawn multiple JVMs? There are reasons why one would like to do that, but what are your reasons? – Bastian

If you are using multiple JVMs, it would be for a good reason and the memory overhead of each JVM should be pretty small compared to the machine you are running on. – Bodywork

Simple put, during development I will have anything in a single process. During deployment I wonder if I can put many different parts in different processes to aid in stability rather than simplicity. To give you an example. If you bring up a recent Chrome version + Selenium on Linux the odds are about 25:1 that the processes gets stuck and you lock up. By placing it in its own process, killing he chrome process if it takes too long, is the answer. Another scenario is running C++ code, isolating it in its own process does not crash your JVM on fault and you can just restart it if it does. – Apparitor

There are many different JVMs. Some have a smaller footprint than others, often at the expense of performance. – Fluctuate

Basically everyone I know uses the Sun VM today. Other VMs are barely used in production as far as i know. Some use augumented VMs during development (to replace classes on the fly and adapt the object graph to the change). – Apparitor

Answer 1

This post describes what makes up a Java application footprint. That is, if you want to reduce footprint, you need to reduce those parts: Java Heap, Metaspace, Code Cache, direct buffers, number of threads etc.

Instances of HotSpot JVM do not communicate to each other for sharing data. Basically they share nothing except for the things shared by the OS, i.e. the dynamic libraries (.so) and read-only memory-mapped files (.jars).

It's up to the application to provide further sharing via IPC mechanisms, e.g. memory-mapped files.

Nog

I looked it up and it is called class data sharing: docs.oracle.com/javase/7/docs/technotes/guides/vm/… It states that it loads data process the classes and than share it for faster load up. In the end it is not what I originally hoped for. But it is different from file access OS caches. – Apparitor

@MartinKersten Right. CDS is a mechanism to map preloaded classes into address space of JVM porcess. CDS image is shared among JVMs as a memory-mapped file. Though I would say it's more about reducing start-up time rather than reducing footprint. – Nog

Answer 2

Probably it will be only a partial answer.

What is the memory footprint of the JVM

The full footprint of a Java app consists of Heap space and non-heap space (let me call it this way). Just a couple of examples of what resides in non-heap space: PermGen or Metaspace, derect allocation from code (malloc), NIO also uses native memeory.

how can I minimize it?

The heap usually occupies the biggest part of you footprint. So, I would start with it.

As for the non-heap space, you can minimize: PermGen (If you max size is redundant), Thread stacks (They are quite large, especially in 64-bit JMMs) and Code cache (insted of performance, of course).

Does those JVM share the JIT cache

In normal conditions (and I'm not aware of others) every process has its own footprint. That's actually what differs a process from a thread. And back to multiple JVMs, each JVM is a separate process.

should share the rt.jar

If you start Java from the same directory (the same installation), of course, they share the same rt.jar, but only as a source of classes. For example, the String class will be loaded as many times as a number of running JVMs.

Woolfell

Answer 3

To complement other answers, here is a couple of insightful articles listing typical JVM memory footprint values and ways to measure them:

https://spring.io/blog/2015/12/10/spring-boot-memory-performance

http://trustmeiamadeveloper.com/2016/03/18/where-is-my-memory-java/

Cynde