Tuning JVM for a VM - Lessons Learned, Directly from VMware
1–10 of 21 posts
Re: Tuning JVM for a VM - Lessons Learned, Directly from VMware
#2Efficiently using memory when you have three levels (Hypervisor->OS->JVM) that are largely opaque to each other is an real challenge. Doing ballooning at the JVM level [0] instead of the OS level makes sense for VMs primarily running Java applications. VMware often seems to be the first to get a new technology out, but their competition quickly follows (e.g. KSM for transparent page sharing and compcache for memory compression). I wonder if Oracle or Red Hat are working on their own JVM ballooning implementation.
[0] http://pubs.vmware.com/vfabric5/topic/.../vfabric-tc-server-...
Re: Tuning JVM for a VM - Lessons Learned, Directly from VMware
#3Efficiently using memory when you have three levels (Hypervisor->OS->JVM) that are largely opaque to each other is an real challenge. Doing ballooning at the JVM level [0] instead of the OS level makes sense for VMs primarily running Java applications. VMware often seems to be the first to get a new technology out, but their competition quickly follows (e.g. KSM for transparent page sharing and compcache for memory c…
[Disclosure: I worked at VMware from 2002 through 2011.]
I take issue with the claim that the competition "quickly followed" on for (at the least) the transparent page sharing feature. VMware was shipping transparent page sharing in their type 1 hypervisor since ESX 1.5, which was released before I joined the company.
KSM was first proposed in 2008, and I believe it didn't actually ship until 2009 (note: the delay was at least in part because the developers wanted to avoid the possibility of exposure to patent litigation since VMware held a patent on the technology, software patents are evil, blah blah).
You can tell a similar story for VMotion/live migration of running virtual machines; VMware first shipped it in 2003 and it was at least 2007 before any competing hypervisors were shipping a similar feature (Hyper-V didn't have it until 2008 R2, Xen had it sooner - possibly in 2007?).
Re: Tuning JVM for a VM - Lessons Learned, Directly from VMware
#4So, how reasonable is it right now to run a JVM directly on a VM?
Re: Tuning JVM for a VM - Lessons Learned, Directly from VMware
#5So, how reasonable is it right now to run a JVM directly on a VM?
Pretty reasonable as proof of concept, MS runs the .NET VM as an operating system, see Singularity. There's also JavaOS, JNode, JX
In practicality the issue is drivers, databases, webservers, etc.
Re: Tuning JVM for a VM - Lessons Learned, Directly from VMware
#6Efficiently using memory when you have three levels (Hypervisor->OS->JVM) that are largely opaque to each other is an real challenge. Doing ballooning at the JVM level [0] instead of the OS level makes sense for VMs primarily running Java applications. VMware often seems to be the first to get a new technology out, but their competition quickly follows (e.g. KSM for transparent page sharing and compcache for memory c…
Azul Systems has been marketing a different solution to this same problem in the Zing VMs for some time now. I believe their solution is based on adding extra APIs to the underlying kernel etc. so the JVM's heap isn't so opaque to the OS/hypervisor.
The VMWare solution sounds like a simpler, pragmatic "hack" to solve the problem. It would be interesting to hear from someone that has used both technologies to see how they compare in practice.
Re: Tuning JVM for a VM - Lessons Learned, Directly from VMware
#7So, how reasonable is it right now to run a JVM directly on a VM?
Pretty reasonable as proof of concept, MS runs the .NET VM as an operating system, see Singularity. There's also JavaOS, JNode, JX In practicality the issue is drivers, databases, webservers, etc.
There are a few ways to solve this; the simplest might be to replace the OS with a library (a libos) linked into the JVM that implements whatever the JVM needs from an OS API in terms of what a specific VM offers. This is the idea of the MIT Exokernel Operating System, XOK.
Re: Tuning JVM for a VM - Lessons Learned, Directly from VMware
#8Efficiently using memory when you have three levels (Hypervisor->OS->JVM) that are largely opaque to each other is an real challenge. Doing ballooning at the JVM level [0] instead of the OS level makes sense for VMs primarily running Java applications. VMware often seems to be the first to get a new technology out, but their competition quickly follows (e.g. KSM for transparent page sharing and compcache for memory c…
That link is broken, can you fix it please?
Re: Tuning JVM for a VM - Lessons Learned, Directly from VMware
#9Or you could just run the JVMs on the base OS and use good old file system security if you really need sandboxing. The supposed advantages of adding a OS VM layer seem iffy if you're just running one app per.
Re: Tuning JVM for a VM - Lessons Learned, Directly from VMware
#10Or you could just run the JVMs on the base OS and use good old file system security if you really need sandboxing. The supposed advantages of adding a OS VM layer seem iffy if you're just running one app per.
It always amazed me that the JVM doesn't have any options to restrict CPU resources (something VMware does have). The only alternative I can think of is to use the unix taskset utility to limit JVMs to specific CPU cores. Anybody got experiece with a setup like this?
Limiting memory usage and file permissions with the JVM is indeed easy.