If you are running multiple VMs on the same machine, you have the option of sharing some of the memory between them. There is a proposal for VMs to share system memory automatically, and this is likely to happen in the future. But currently (as of the 1.4 release), if you want to share memory between VM processes, you need to run multiple pseudoprocesses within one VM process. The necessary techniques are actually quite complicated, as many subtle problems can arise when trying to run several applications in the same VM while keeping them independent of each other.
Fortunately, there is a free open source library called Echidna (available from http://www.javagroup.org/echidna/) that takes care of all the subtleties involved in running multiple applications independently within the same VM system process. The library also provides several management tools to help use Echidna effectively. If you want to know how Echidna works or need to use parts of the library within your project, I have written an article that covers the technology in some detail.[2]
[2] "Catching OutOfMemoryErrors to Preserve Monitoring and Server Processes," OnJava magazine, August 2001, http://www.onjava.com/pub/a/onjava/2001/08/22/optimization.html.
The shared-memory advantages from combining multiple applications into one VM are significant for applications with small memory requirements where the VM memory overhead is significant by comparison. But for applications that require large amounts of memory, there may be little benefit.
A shared-memory VM also provides a faster startup time, as the VM can already be running when the application is started. For example, a VM using the Echidna library can be a running system process with no Java application running (except for the Echidna library). The Echidna library can start any Java application in exactly the same way the VM would have started it, but without all the VM startup overhead.