Why have one JVM per application?

Question

I read that each application runs in its own JVM. Why is it so ? Why don't they make one JVM run 2 or more apps ?

I read a SO post, but could not get the answers there. Is there one JVM per Java application?

I am talking about applications launched via a public static void main(String[]) method ...)

Answer 1

(I assume you are talking about applications launched via a public static void main(String[]) method ...)

In theory you can run multiple applications in a JVM. In practice, they can interfere with each other in various ways. For example:

• The JVM has one set of System.in/out/err, one default encoding, one default locale, one set of system properties, and so on. If one application changes these, it affects all applications.
• Any application that calls System.exit() will effectively kill all applications.
• If one application goes wild, and consumes too much CPU or memory it will affect the other applications too.

In short, there are lots of problems. People have tried hard to make this work, but they have never really succeeded. One example is the Echidna library, though that project has been quiet for ~10 years. JNode is another example, though they (actually we) "cheated" by hacking core Java classes (like java.lang.System) so that each application got what appeared to be independent versions of System.in/out/err, the System properties and so on¹.

^{1 - This ("proclets") was supposed to be an interim hack, pending a proper solution using true "isolates". But isolates support stalled, primarily because the JNode architecture used a single address space with no obvious way to separate "system" and "user" stuff. So while we could create APIs that matched the isolate APIs, key isolate functionality (like cleanly killing an isolate) was virtually impossible to implement. Or at least, that was/is my view.}

Answer 2

Reason to have one JVM pre application, basically same having OS process per application. Here are few reasons why to have a process per application.

• Application bug will not bring down / corrupt data in other applications sharing same process.
• System resources are accounted per process hence per application.
• Terminating process will automatically release all associated resources (application may not clean up for itself, so sharing processes may produce resource leaks).

Well some applications such a Chrome go even further creating multiple processes to isolate different tabs and plugins.

Speaking of Java there are few more reasons not to share JVM.

• Heap space maintenance penalty is higher with large heap size. Multiple smaller independent heaps easier to manage.
• It is fairly hard to unload "application" in JVM (there to many subtle reasons for it to stay in memory even if it is not running).
• JVM have a lot of tuning option which you may want to tailor for an application.

Though there are several cases there JVM is actually shared between application:

• Application servers and servlet containers (e.g. Tomcat). Server side Java specs are designed with shared server JVM and dynamic loading/unloading applications in mind.
• There few attempts to create shared JVM utility for CLI applications (e.g. nailgun)

But in practice, even in server side java, it usually better to use JVM (or several) per applications, for reasons mentioned above.

Answer 3

For isolating execution contexts.

If one of the processes hangs, or fails, or it's security is compromised, the others don't get affected.

I think having separate runtimes also helps GC, because it has less references to handle than if it was altogether.

Besides, why would you run them all in one JVM?

Answer 4

Java Application Servers, like JBoss, are design to run many applications in one JVM