Before we start, please check out
Grzegorz Czajkowski's blog. Greg talks a bit about the technology and has links
to related sites (including, of course, the
project page for MVM.
Note, however that you will need the
JDK Researcher role in order to view the project). I'll wait here;
you go ahead and check it out now.
All done? You read the blog, saw the project, formed some opinions?
All right, then; let's go!
It seems like MVM is one of the hair-triggers for Java developers. Whenever
I hear it mentioned, the comments are along the lines of "We need MVM!", or
"Why isn't it in the platform yet?", or "It'll be in the next release for sure."
Whenever we query developers about what they'd like to see, the answer is
usually "MVM!" How do we improve startup performance? "MVM!" How do
we improve application footprint? "MVM!" What do you think of the new
graphics acceleration features? "MVM!" There are forums devoted the
subject, rants on popular developer sites, and generally entertaining and
highly-charged discussions with
lots of exclamation points and death threats.
So given all of the excitement around MVM, why isn't it in the platform yet?
Why aren't we planning on putting it there, at least in Mustang? What are
we thinking? I mean, obviously everyone wants it, so why don't we listen
to our community and just put it there?
First of all, let's take a little step back and think about what MVM is.
In particular, I'll focus on the aspects about MVM that caught everyone's
attention (including mine) initially; startup and footprint benefits.
As Greg says in his blog, there's a lot more exciting stuff in there,
especially the Application Isolation API. But I wanted to specifically
address the performance aspects of MVM and what they mean (and don't
mean) to typical desktop applications.
Basically, MVM provides a way to launch separate Java applications in the
same virtual machine. Currently, separate Java applications all run in their
own process, completely independent of one another. There is some very
simple sharing happening under the hood in terms of shared libraries
(specifically, the DLL's on Windows, the .so's on Unix, and some of the
Java classfile data on all platforms). But other that this basic OS-level
sharing, all of the processes are completely independent.
This process independence means that every new Java instance fires up its
own copy of the executable, loads in its own classes, creates its
own heap, and suffers its own startup performance hit (whatever it is).
There is significant startup benefit from being the second Java application
in general, but this is due to the disk caching happening at the
operating system level, not due to any sharing between our Java processes.
Two things that bug some desktop Java users (and, by the transitive property of
software usage, the developers of Java applications) have complained about
over the years are the time that applications take to startup, and the
RAM footprint that these applications consume on the machine. Startup time
has actually gotten much better over time, through a combination of
Class Data Sharing (implemented in Tiger, a nifty way of preloading all of
the core classes that desktop apps usually need), various performance
tweaks, and the inevitable speedup of processors, disks, and operating
systems. Footprint continues to be an issue, although with standard PC
memory configurations, this is less of an issue now just because the
footprint occupies a lesser proportion of a machine's RAM when that machine
comes with so much to begin with. But both are important issues that we should
(and do) continue to work on.
Along comes MVM, which has this nifty property of sharing process overhead.
Startup: Each new Java application has a nearly free startup of the core
VM and classes that are already loaded. Obviously, an application would
still take time to load in their own classes, but the stuff that was
already loaded by other MVM apps would come for free.
Footprint: Each new Java application takes up only the additional footprint
for extra heap it requires and extra classes it loads; the footprint
required for core classes shared with other Java applications is once
Free? Did you say Free? Where can I get some? We need this!
Why isn't it in the platform yet? It'll be in the next release for sure.
Okay, let me don my loud plaid suit and play the part of a used car salesman:
"Well, it's really almost completely free ... but not quite." Here are the
gotchas about this approach that are important to keep in mind before getting
too swayed by the "Free" argument above:
Someone's gotta take the hit: Obviously, MVM cannot magically make the
startup and footprint issues go away completely; that stuff still has
to be loaded from disk and stored in memory. So somewhere there will
be a startup hit loading the data and a RAM footprint to hold the heap
and class data. In particular, this hit will be taken by the first
application to load into MVM (or perhaps some parent process that
simply loads up MVM to begin with). It is the following Java
applications (from the second one on) that get the benefit of the
All for One and One for All: If all of these Java applications are running
within the same process, this means that any one of them can kill all
of them. I believe that MVM protects around simple things like
calls to System.exit() and other Bad Things happening at the Java level.
But what if some native code does something awful and crashes?
Or worse, what if some native code calls into some driver or other
operating system dependency and _that_ crashes? Then that crash will
also take down the whole lot of them.
So these are what my reservations for Desktop apps using MVM really boil down
to: the benefit is only there for situations where multiple Java applications
are running simultaneously, and there is significant risk that one application
can take down the lot of them.
The risk of crashing all apps running within MVM is so important that I would
feel queasy about sticking in this kind of capability by default in the
platform. I cannot be sure that all applications that your users will
run will be robust enough (from the application down through the platform
level down through the drivers and into the hardware) that I'm will to bet
all of your users' other applications upon that.
And given that the MVM benefits of startup and footprint are visible only
for situations in which multiple Java applications are running, it seems
like the only interesting environment in which to run MVM is one in
which multiple Java applications are running.
Let's put these things together: we don't want to run MVM by default due to
the kill-them-all risk, and we only want to run MVM in situations in which
there are multiple Java applications at work. It sounds to me like we've
just entered a new category of Java applications which does not yet exist:
The ideal situation I envision for MVM is one in which applications run
in suites, or in some other way where they could elect to have themselves added to
a particular MVM process. For example, someone might ship a desktop utilities
suite, and other developers could add in other applications that want to
run in that process. Or someone could supply a suite of related applications
(CAD, office, linked enterprise apps) that are happy to live (and maybe
die) together. Or there could be a "Game" suite that you could elect
to run your game in (crashing all games running is less serious than crashing
all air traffic control applications, for example). Or there could be something
I'm not yet seeing, because it doesn't yet exist.
So? Why isn't it there yet?
So now, finally, I get down to the question of "Why isn't it in the platform yet?",
or more specifically, why isn't MVM going to be included in Mustang?
Well, frankly, it's always a question of tradeoffs, just like any
Would we include it if we could? Sure! Given the
caveats above (that it's not enabled by default, that there are mechanisms
for running related applications in separate MVM processes, etc.), then
I don't see a good technical reason why we couldn't ship it. But, given
the niche category that I've backed this technology into with the reasoning
above, is it a critical feature that we should focus on in preference
to some other Mustang feature? Given that we have a finite number of developers,
that there are lots of interesting features and fixes we are working on
(that people are also screaming for), and that not everything can make it
onto the Mustang plate, I believe we made the correct call here that
MVM, seen in the light of my logic above, was simply not as important
as other features that we elected to work on instead. Would you rather we
spent our efforts on technologies that benefit all, or even most, of
Java developers? Or on a feature like MVM which might be completely
awesome for the folks that need it, but which (given the constraints I laid
out above) are probably few in number today?
What do you think?
What would you do? Am I missing something here? Is there a vibrant community
of "application suite" developers that's just waiting to happen? Or are there
a preponderance of applications that would be willing to work within these
constraints today? Join in a discussion above, or go to Greg's blog and
hop onto discussions there. We're looking for feedback on this; we'd like
to take the MVM discussion of the "We need it!" stage and into the "We
understand the constraints, here's how we would like to use MVM."