IBM Java 8 open beta has been available since September 2013 and this is not a new news, but milti-tenant capability becomes much more important in light of the Cloud announcement made by IBM this week. Imagine how cool it will be to use multi-tenant JVM to run your Java or Java EE applications not only on the cloud, but on premise?
Let me explain what multi-tenant JVM really is. In a traditional model every time you type “java xyz” you start new operating system process and run single application per OS process with entire JVM dedicated to serving your app. If you have very large application (say WebSphere Application Server Network Deployment) with many different different WAR and EAR files deployed into that server having one JVM per “application” is not a bad idea. In this case WAS ND provides “operating environment” for multiple applications that you deployed into it and it makes a good use of the JVM and OS resources and under high load with proper tuning and proper applications can consume up to 100% of CPU and memory available to the OS. This is how JVMs from OpenJDK, Sun JDK and IBM JDK used to work in the past (and still do).
Now imagine different environment. What if you do not have one GIGANTIC high load application? What if you have hundreds (or thousands) of small applications and services and they may or may not be highly loaded? With Tomcat, WebLogic or JBoss on top of traditional JVM you can still deploy those apps and services as independent EARs and WARs and there will be certain amount of isolation provided by the JVM, but you will certainly have issues with singleton patterns and potentially other administration and security issues. This is why there are multiple different levels of isolation ranging from separating hardware servers with real brick and steel walls, to OS virtualization with KVM, VMware to running multiple JVM instances on the same OS. Each of these methods has a benefit (level of security and independence), but it has disadvantages – mainly high resource requirements resulting in high costs (need too much memory, too many cores, too many software licenses, etc.).
Multi-tenant JVM provides an excellent compromise and offers the best of both worlds – good level of isolation with very little overhead. To quote IBM developerWorks article on the benefits of multi-tenant JVM:“… The main benefit of using the multitenant JVM is that deployments avoid the memory consumption that’s typically associated with using multiple standard JVMs. This overhead has several causes:
- The Java heap consumes hundreds of megabytes of memory. Heap objects cannot be shared between JVMs, even when the objects are identical. Furthermore, JVMs tend to use all of the heap that’s allocated to them even if they need the peak amount for only a short time.
- The Just-in-time (JIT) compiler consumes tens of megabytes of memory, because generated code is private and consumes memory. Generated code also takes significant processor cycles to produce, which steals time from applications.
- Internal artifacts for classes (many of which, such as
Hashtable, exist for all applications) consume memory. One instance of each of these artifacts exists for each JVM.
- Each JVM has a garbage-collector helper thread per core by default and also has multiple compilation threads. Compilation or garbage-collection activity can occur simultaneously in one or more of the JVMs, which can be suboptimal as the JVMs will compete for limited processor time.
IBM has measured application density and startup times and published very impressive results – and that is all using open beta version of the JVM. Imagine being able to run 4 times more instances without having to spend more money for memory, CPUs or licenses! That is very impressive indeed:
To see complete explanation of these tables, please read full article on IBM developerWorks. To be fare, IBM is not the only vendor working on multi-tenant JVMs, but IBM is the first mainstream JVM provider with this capability.
I can’t wait when IBM starts shipping products on top of this new JVM!