Debugging: You can step from one service into another in the same debugging sesssion.
Profiling: Analyse one snapshot to find the main bottleneck across a number of services.
Performance, security etc. etc. Basically the ability to use a lot of the things that make the JVM powerful and save you time and money. (Not only that but the things that make clojure powerful like its concurrency mechanisms etc across services)
Besides one process is often simpler than many. Interprocess communication suffers from some of the "Fallacies of Distributed Computing."
If you like to keep your UNIX process mental model just think of JVM threads as processes.
(One other thing: Running services in multiple JVMs uses more heap than multiple services in one)
That is a natural feature of garbage collection. The asymptotic complexity of copying garbage collection is O(complexity of live object graph)/(total available heap size). That is, having more heap available makes it consume less computational resources, up to an including making many real loads have near-zero garbage collection cost if the heap is large enough. Having three individual processes share a heap can make them actually do less work than if they each had a static third.
Modern operating systems are not set up to exploit this. There has actually been some work done on Linux user space reclaim for it but it's not yet usable. Until there is a way to tell the kernel that you want to use every last free byte on the machine if possible but can likely free most of it when any other process needs it, to make best use of the machine you will have to roll your own in userspace.
You are also putting multiple independent services in the same fault domain.
In practice, unless you are doing a few stupid things (which most places don't let you do), it's extremely uncommon for whole JVM processes to go down. With a bit of work you can make almost all faults only take out individual tasks.
Not that I personally like JVM. I'd much prefer to do work on the actual OS, not wrap it all and pretend it doesn't exist. However, the people who build and use it are not idiots -- there is an actual method to their madness.
Comments
Debugging: You can step from one service into another in the same debugging sesssion.
Profiling: Analyse one snapshot to find the main bottleneck across a number of services.
Performance, security etc. etc. Basically the ability to use a lot of the things that make the JVM powerful and save you time and money. (Not only that but the things that make clojure powerful like its concurrency mechanisms etc across services)
Besides one process is often simpler than many. Interprocess communication suffers from some of the "Fallacies of Distributed Computing."
If you like to keep your UNIX process mental model just think of JVM threads as processes.
(One other thing: Running services in multiple JVMs uses more heap than multiple services in one)
That sounds like a failure of the JVM. You are also putting multiple independent services in the same fault domain.
That is a natural feature of garbage collection. The asymptotic complexity of copying garbage collection is O(complexity of live object graph)/(total available heap size). That is, having more heap available makes it consume less computational resources, up to an including making many real loads have near-zero garbage collection cost if the heap is large enough. Having three individual processes share a heap can make them actually do less work than if they each had a static third.
Modern operating systems are not set up to exploit this. There has actually been some work done on Linux user space reclaim for it but it's not yet usable. Until there is a way to tell the kernel that you want to use every last free byte on the machine if possible but can likely free most of it when any other process needs it, to make best use of the machine you will have to roll your own in userspace.
In practice, unless you are doing a few stupid things (which most places don't let you do), it's extremely uncommon for whole JVM processes to go down. With a bit of work you can make almost all faults only take out individual tasks.
Not that I personally like JVM. I'd much prefer to do work on the actual OS, not wrap it all and pretend it doesn't exist. However, the people who build and use it are not idiots -- there is an actual method to their madness.
Actually, there is already (proprietary) multitenancy support for the jvm that provide full isolation (minus JNI calls). See http://www.ibm.com/developerworks/library/j-multitenant-java... .
IIRC I saw some talks about introducing it in java9.