I tried not to get a swelled head when Stu Radnidge conferred divine status upon me some years ago. After all Stu grew up in the Australian wilderness and I suppose riding a kangaroo to school every day could lead to a warped sense of reality.
So it was refreshingly deflating to find that nobody even noticed my VMworld session (2917 vote for me). In fact permit me to helpfully reproduce what you would have seen if you had voted for me as you should.
Elastic Memory for Java is a project I’ve been helping out with for the past year or so that aims to let you run Java apps on ESX without having to give them all their memory all the time. Java apps run great on ESX, so long as they have all the memory they want. If they don’t, things can go south really quick.
This is a big problem because Java likes to be lazy about cleaning up after itself, and prefers to hold on to every piece of trash and dead memory in sight until it nearly collapses under its own weight. It’s sort of like the software world’s answer to the Collyer brothers.
This behavior also explains why traditional ballooning in ESX doesn’t work well with Java. EM4J is different because it’s designed to work within Java and has intimate understanding of what’s happening in the Java app. If you wanna find out more, you gotta come to the session.
Why is VMware doing this you ask?
- Efficiency is in.
- We’re on the precipice of an app explosion. We’ve already seen it in consumer space, more special purpose apps that individually do less than monolithic apps of the past. This is infiltrating enterprise and when it does we need an order-of-magnitude or two more consolidation to cope with it.
- Oh yeah and cloud. Cloud cloud cloud cloud cloud. There I said it.
P.S. If you’re interested in trying Elastic Memory for Java out, we’re running a select beta. Message me on twitter or email me at cshanklin at vmware com and let me know you’re out there.
Otherwise see you in Vegas!