New Multitasking VM Does More for Small Devices

Story by Al Riske. Photography by Howard Friedenberg.

February 17, 2009 - Laurent Daynes has been working on a different kind of virtual machine — a multitasking virtual machine — and so far the results have been impressive.

Unlike humans who are less efficient when they try to multitask, the MVM shines when running many applications at once.

For one thing, it can cut startup time in half.

For another, it runs multiple applications with a much smaller footprint than the current VM.

"In some cases we've seen that the footprint of running up to 10 instances of the same application was less than twice the footprint of running a single application with a VM that is not capable of multitasking," says Daynes a senior staff engineer in Sun Labs.

Those two issues — startup time and footprint — were the reasons Daynes and then-colleague Greg Czajkowski started their investigation into different ways of executing Java programs back in 2001.

"The original project was called Barcelona. Back then, Java was being pinned down by a lot of critics, mostly because of its poor handling of small programs. It was not fit for running small programs or scripting environments," Daynes recalls. "The footprint of the system was also being criticized in the sense that it was getting way too big."

The Barcelona team first created a prototype based on the HotSpot virtual machine for the Java Platform, Standard Edition, which they later transferred -- by request -- to the Connected Limited Device Configuration, or CLDC, a virtual machine for resource-constrained devices such as mobile phones. That technology, co-implemented with the product team, has been shipping as part of the Java Platform, Micro Edition, since 2004.

The Barcelona project ended in 2005, but now there is renewed interest, so Daynes is picking up where he left off.

What triggered the renewed interest?

"The reason is small devices are not that small anymore, and people want the full power of Java, not just a subset, which is what the Java ME profile is," Daynes explains.

Here it may be worth noting that Java's platform independence has always come at a price.

"The reason startup and footprint are pretty bad with the VM -- and this is still the case today -- is because, contrary to other programming languages like C or C++, the Java VM re-creates the entire image of the program in main memory," he says.

And it doesn't share class libraries between different programs.

"The fact that you do not share means you increase the footprint when you run more than one program," he says, "and the fact that you have to re-create that every time you execute is killing your startup time."

The new MVM, on the other hand, knows how to share. So it does less work but gets more done.

"The nice feature of type-safe programming languages like Java is that no one can create their own pointers and just tap into anyplace in memory. The language provides basic protection so you can run two entire programs within the same address space -- within the same operating system process -- without anyone noticing this, because they can't go and start messing around with the data of the other program. Once you've got that basic feature you can modify the VM to enable the execution of multiple programs," Daynes says.

Why run multiple programs within the same process? To facilitate sharing of the metadata structure that the VM creates.

Right now, Daynes says, every time you start a Java program, a VM is created, which in turn creates a representation of the program optimized for execution in main memory.

"All of that gets lost as soon as the program terminates," he says. "If you start another one, you have to do exactly the same work. None of this is shared."

While some sharing has been possible, it has always been complicated because the dynamic nature of the VM means there is no guarantee that links between the various classes will be resolved in the same way each time.

But Daynes and Czajkowski found a way around that.

"Before the program starts executing, we check that the set of specified classes is the same set as what we already have in the VM, and if that is the case, we have the guarantee that we can share them because we know they are going to link exactly the same way," he says.

"The MVM verifies that that class path is something it's already using from some other application or has used in the past. Therefore, when the new application comes, the VM can decide, 'Well, I've already got that in main memory, so whenever these guys ask me for class A, B, or C, rather than fetching this stuff and creating new copies, I'll just tap into what I've already got in main memory."

But there's a trick to it.

"What you need to do is look at all the data structure used to represent a class in the program main memory and make the modifications to them so you segregate what is program specific and what is not," Daynes says.

"So you share whatever is not program specific and you duplicate what is -- and you do that on the fly."

Daynes has MVM prototypes for JDK 7 working on Solaris and Linux and is now testing a preliminary version for Microsoft Windows.

"That will be provided to the product team so they can investigate the technology and evaluate the amount of change required to support the full platform," he says. "Right now, for Windows, we've been doing what's called a headless port. Headless means you're not using any graphics. So none of the GUI stuff."

Here he notes that the Java libraries themselves are not written entirely in Java. Some of them contain code native to the platform they will run on, which, if not done right, could undermine the reliability of the JVM when running multiple programs.

"So some of the native code, especially the native code for the core classes, may have to be modified to be made multitasking safe," he says.

"The current barrier is: How hard will it be to make the native Windows code multitasking safe? We are in the process of looking at this. As long as you're not speaking graphics, it's fairly easy -- we've done it. But for graphics it's a completely different story."

Since he is not a Windows programmer he will leave graphics to the product team.

"That's the reason they asked to see a first prototype of the multitasking virtual machine on Windows -- so they can investigate how much it would take to modify the native code."