JVM sharing memory

Question

I have some doubts in JAVA. I have a task executor which will create a new Thread for each task and each thread will execute a task from jar by

Runtime.getRuntime().exec(" java -jar myjar");

I read in some posts that by executing like this each thread will create its own JVM. Then if I want to execute the same class or a different class from the same jar using two threads it will create a copy of same jar in two JVMs. Actually I want to avoid copying same jar in two JVMs. Instead of that I want to share same jar between multiple JVMs.

Please give some hints about this situation.

Answer 1

A JVM doesn't need its own copy of a jar. It just needs to find it in its classpath. The same jar can be in the classpath of several running java programs.

Of course, each JVM has its own memory, and the classes from the jars in its classpath will be loaded in the memory of each JVM. Sharing the same memory for the classes loaded by two different JVMs is impossible. If you want to share memory, don't use several Java processes, but use threads instead.

Answer 2

You're not really "copying a jar" into a JVM. You're loading classes from it, and only those classes that are needed. Now unless you somehow managed to get lots of class files of several MiB in size and spawning dozens of these processes, it shouldn't be much of a problem. You're much better off just letting each JVM process take care of its own problems and keep things simple. When running multiple JVMs there's a good chance you have some optimization going on in the background anyway. Don't second-guess the implementation optimizations.

If this really is an absolute requirement for some reason, you're in for a difficult ride. The only solution I can think of is writing a custom classloader that somehow uses shared memory. And that would most likely involve the use of the Java Native Interface, forcing you to write platform-specific code. Perhaps there's some available solution out there, but I know of no such thing.

And this is all assuming you should be spawning other Java processes in the first place. I think you'll be better off looking into a way of having those other processes running in separate threads instead within the same Java process. The Java concurrency utils (in package java.util.concurrent ) have made such things quite a bit more manageable.

The HotSpot JVM itself uses class data sharing on the system jar file to reduce memory footprint and speed up the booting of multiple JVMs. Perhaps the source code can provide some ideas. But I think this should be absolutely the last thing to try to solve whatever issue you have. Unless you're running into serious memory problems and really, really need multiple processes, you're trying to optimize something you should stay far away from.

Answer 3

(You can of course have two JVMs sharing a JAR file, and this doesn't "create a copy" of the JAR files ... but I don't think this is what you really mean by your question.)

---

Sun/Oracle Java has a feature called CDS (introduce in Java 5.0) that allows classes loaded from "rt.jar" to be shared across multiple JVM instances. The compiled classes are saved to something known as the "shared archive" which can then be memory-mapped into the address space of multiple JVMs ... to speed up JVM startup. However, CDS isn't available for application classes.

Apparently IBM's implementation of Java 5 has a similar feature called "Shared Classes" which works for application classes as well.

---

You may save some memory this way, but it is not clear that you will save a significant amount of memory. If you are really concerned about memory usage and JVM startup times, you are better of running the child Java applications in the parent JVM. (The downside of course is that if any one of the child Java applications misbehaves it can cause problems that can only be resolved by exiting the parent JVM.)