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?

Solution 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.

Solution 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.

Solution 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/

Comments

[Martin Kersten]

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.

[apangin]

@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.