Hacker News Reader

Comment by sciurus | Hacker News Reader

Efficiently 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-...

View on HN

[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?).

Out of curiosity what made you leave VMware?

Thanks for the correction!

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.

As I understand it, Azul rather solves this problem by giving control of the memory-mapping unit to the VM. Which allows some really neat tricks (I'd expect it also allows VM->kernel privilege escalation, but their machines are Java appliances anyway.)

That link is broken, can you fix it please?

Sorry, try http://pubs.vmware.com/vfabric5/topic/com.vmware.ICbase/PDF/...

Reply on news.ycombinator.com