Multiple JVMS, Pros and Cons, The Basics

Modern enterprise computing systems supporting Java, especially Java2 Enterprise Edition (J2EE), commonly provide mechanisms for supporting multiple Java Virtual Machines (JVMs) to run at the same time. What is this and why would you want (or not want) to do this?

If we begin with a basic understanding of computing hardware (memory, CPU, disk, network cards, etc.) and operating systems (Windows Vista, LINUX, Solaris, etc.) then we have the basics for understanding what multiple JVMs are and why they might be used. With any computing hardware and operating system combination (Intel + Windows XP, Intel + LINUX, Mac + OS X, SPARC + Solaris, Sparc + LINUX, etc.) we expect a basic set of services to be available with which we can run programs, store data, communicate over networks, etc.

One of the key ideas behind Java was to build a layer on top of the established hardware and operating system platforms that provided its own definition of a computing environment with all of those same services (computation, input/output, communication, etc.) we expect of a hardware-OS combination. Why the redundancy? Because the assertion was (and largely proven true) that there would be some value in allowing developers to break free from writing programs for a specific hardware-OS combination but for this new Java layer that could be added on top of a variety of hardware-OS combinations.

Since the Java environment provides so many of the computing services expected from a hardware-OS environment but is actually just a software layer, it was referred to as a "virtual machine".

Mmmm, but if the Java virtual machine is just a piece of software running on top of another hardware-OS stack (say, Intel and Windows Server 2003) and that hardware-OS stack allows lots of pieces of software to run at the same time, then what is to prevent one from running multiple Java virutal machines at the same time? The answer is "nothing" and this is commonly done.

Why might a person run multiple JVMs at the same time?

1.) To isolate errant programs. If you have two applications, run them in the same JVM, and one of them does something to crash the JVM then it will take the other application down with it. Running applications, or sets of applications, in separate JVMs allows one to limit the consequences of errant programs.

2.) To run multiple versions of the JVM at the same time. Java has evolved a lot over the past 5-10 years. There are new features in the basic syntax of the language, new features in the libraries available, etc. The existing set of features in J2EE is huge. Running multiple JVM gives us two benefits in this regard. If you have "older" Java apps written for a Java syntax that has been deprecated or no longer supported and "new" Java apps that will only run onthe latest and greatest version of Java, you can run two differently configured JVMs but keep them on the same hardware - they will for example be able to share disk space. Similarly, when using the current spec. of J2SE/J2EE you might desire to have different environments that include/exclude different sets of the J2SE/J2EE feature sets - e.g. you might want an environment that does support EJBs and one that doesn't.

Why might a person not want to run multiple JVMs at the same time?

1.) Performance is one reason. There is some small overhead associated with the hardware-OS running multiple environments. So multiple JVMs may not be the best choice if you have a small number of applications, not prone to crashing, with no differences in the J2SE/J2EE features but needing as much performance in use of CPU, RAM, etc. For example, if you are using the Singleton or Flyweight pattern to make your applications memory efficient you will only get the benefits within the JVM and not across the JVMs.

2.) Inter-process communication. Related to the comment above about sharing objects, there are interprocess communication options available for applications within the same JVM that won't work (or as well) across JVMs. Doesn't mean apps in separate JVMs can't communicate - they can - but there is an impact here.

There are illustrative examples of the pros and cons - by no means a complete list. For more on this topic I recommend reading The Java Tutorial, The J2EE Tutorial, and Designing Enterprise Applications for the J2EE Platform. These focus on J2EE. This issue applies to non-J2EE uses of Java but I'm mostly familiar with J2EE and that seems to be the area most people have questions about.