Tags: Java
I see there's
some excitement over Chet's MVM weblog posting.
My bailiwick here is Quality, so I just want to toss in a comment on the MVM subject from this point of view.
Let me start by saying MVM is an interesting idea ... I've heard the MVM give his presentation to the Performance group, of which Chet is a part. He's certainly done some really good work to solve some really sticky problems with how you'd write a Java VM that would share applications.
Chet mentioned in his posting the issue I have, from a Quality perspective that is. Namely: If that MVM process were to crash, it would take down all Java applications running on the system. All.
This is so obviously a problem, that I'm surprised with the emphaticness of the people pushing for MVM. If we put MVM into the platform your complaints would turn from "it's slow" to "it crashes all my applications". No matter how stable Java has become, it still has bugs, and there's still lots of ways to crash it. That won't change under MVM.
Which means expending effort on ways to isolate crashes in the native code. It's not just JNI calls that are at issue, there's quite a bit more native code lying around such as (ahem) hotspot, the garbage collector, etc. All of that can crash. As some of the commenters in Chet's thread pointed out, there are C level techniques for catching that level of crash and doing something like turning it into a Java exception. That would help in some cases, but for example the garbage collector generally stops the VM so it can collect garbage. What if the garbage collector crashes while the VM is stopped?
In short there's a lot more research to be done into this idea.
UPDATE: I suppose I should mention these disclaimers ... I haven't actually run mvm ... it's been awhile since I looked at any mvm docs, maybe the researcher has already addressed some of the problems I mentioned ... and finally, while I work in the Quality team, I have no say in whether mvm gets "in" or not, this is purely my opinion.
Source:
weblogs.java.net
Comments
David,"If that MVM process were to crash, it would take down all Java applications running on the system. All. " Forgive my MVM ignorance... is it not possible to run multiple MVMs on a system? --John
Posted by: johnreynolds on July 25, 2005 at 08:44 AM
I'm sorry - I meant that to say "all Java applications associated with that MVM".
- David Posted by: robogeek on July 25, 2005 at 09:06 AM
We no longer feel the need to have a process dedicated to each request to a server. Isn't that the same sort of thing as running multiple small desktop applications in an MVM?
I appreciate that desktop applications will run a broader range of native code. Are there any stats for what and how frequently JVMs crash? I used to have a crash everytime a process that had used AWT exited.
Posted by: tackline on July 25, 2005 at 11:32 AM
Since the MVM is an optional run time environment, any instability wouldn't put any current application any farther behind than before -- since they can always fall back on running Java with seperate JVMs.
This fear of stability is, IMHO, irrational. I know that the JVM crashes. I've seen it. It's happened to me. But, for me, it has been a remarkably rare event, perhaps it's more common for others.
But for me, I hit OOM a heck of a lot more often than crashing the JVM, and we deal with the problem.
From a Quality perspective, you should be focusing on making sure that the MVM itself doesn't crash itself, rather than worrying what horrors users may subject it too. Let them crash their MVMs.
Even an MVM that faults and crashes at the slightest rogue Unix Signal is better for some applications than no MVM at all.
Most of us here who write Java do simply that -- write Java. We write Java that depends on other Java. Most of us are 100% pure Java, because it's one of the many aspects of the platform that attracts us to it.
If the J/MVM is buggy, then Pure Java(tm) can potentially crash it. But, as time goes on, it's more and more unlikely.
With the expansion of technologies in the JRE itself, less and less "customer supplied" native code is necessary, meaning that y'all can test your inter JVM bits and provided JNI bits against MVM until you're happy that they're safe and stable.
Once you've done that, you've achieved the best result possible: a stable MVM ready to abused and blown up by developers and customers.
If I write a Perl program, I have a very high expectation that regardless of what I'm doing, my Unix system will survive in some form. Perl shouldn't be able to kill my box. But if I were dabbling in Kernel modules, etc., then I have no such expectations. I'm going outside the realms of protection provided by the system and take my chances.
The same can be said of the MVM. Publish and document the safe areas, warn us of the dangerous areas, and let fly. We're all adults and can take our own medicine when we grenade our MVM.
If, say, Weblogic explodes the MVM, and BEA says that it was OK that Weblogic runs in the MVM, I can guarantee I'll be on the phone to BEA and not Sun because my MVM imploded one day.
So, don't worry about it, perform some due dilligence, test it to within scope, publish the limitations, and let it go. We can handle it. Don't worry about us.
Posted by: whartung on July 25, 2005 at 12:33 PM
The case you're missing here is where people are already running multiple pieces of Java code in a single VM instance. For example, each piece of code in a different class loader. Applications like this have already faced and accepted the risk that one piece of code could totally crash the system. For these applications, MVM would offer a significant improvement in reliability compared to "just" class loaders.
Posted by: desperado on July 27, 2005 at 05:37 AM
Okay ... applications that use lots of classloaders. Netbeans is an example (it uses one classloader per module, and it loads LOTS of modules), and I'm sure in appservers they have at least one classloader per webapp that's installed, etc.
But, that's all within one application. If one of those classes causes the JVM to crash, that's one application affected. Well, except for the shared hosting case involving a hosting provider sharing a single appserver instance with multiple sites. If one of those sites has code that crashes the JVM, then all the sites goes down at once.
In the MVM case the idea is to be controlling lots of applications from one MVM thingy. For example the shared hosting case, you'd run one appserver instance per account on the shared server, and be able to share lots of memory between them -- whereas the only way to share that memory today is to put them all in the same JVM instance. Another example is a desktop environment running lots of Java applications, and sharing memory use between them. From Sun's standpoint the even bigger example of that is the Sunray environment - think "X Terminal" with 100 or so people on the same compute server (except it's much nicer than any X Terminal I've ever used before).
In all those cases a crash of the MVM takes out lots of users.
One of the commenters suggested a packaging arrangement. That you'd have the "java" command for the traditional Java use, and perhaps a "java_mvm" command to run in mvm mode. That has some merit ... and I could see that as a transitionary vehicle. No way that would appear in Mustang, given where we are in the Mustang schedule, however.
Like I said in my disclaimers .. I have no idea how buggy MVM is (or not). I just know from experience, MVM is gonna be lots more complicated than the current JVM model. More complication means (generally) more ways to crash. And given the model, any crash has greater consequences. And those greater consequences means that the public will have a new thing to complain about.
Posted by: robogeek on July 27, 2005 at 07:54 AM
It seems I wasn't clear enough. I believe there are systems today running multiple applications in single JVM instances using class loaders. i.e. taking a risk significantly higher than the one you seem to believe is unreasonable. For people or organisations who have decided this risk is acceptable with todays VMs, MVM will be an improvement.
Posted by: desperado on July 27, 2005 at 11:27 AM
Okay, can you say a little more?
What I know about are the aforementioned shared hosting arrangement ... and that there's a couple projects I categorized as Java Desktop Environments where they create some kinda pseudo desktop to run multiple applications in a single JVM on a single pseudo desktop.
Sounds like you're there's systems out there where multiple users, on multiple terminals, each have an application window with all the applications running from one JVM...?
Posted by: robogeek on July 27, 2005 at 11:41 AM
CHOICE! Give us CHOICE! If we want to crash-test MVM - that's our choice! :) Something like java -mvm (just like current java -server and java -client) would suffice.
That said - the startup time of java in 1.5 is pretty satisfactory already, even on my two-and-a-half-year-old box. So IMVHO the biggest gain would be shared memory for common classes, which in itself is very desirable.
Posted by: jezuch on July 27, 2005 at 03:50 PM
What if giving you the "java -mvm" choice would so greatly complicate "java" for non-mvm users that it decreased the reliability of Java for them? I think generally we balance choice and readiness when delivering technology. For example when the XAWT was implemented it was not the default setting for Solaris, since it was such a drastic change it wasn't known how stable it really was.
BTW, one of the 1.5 features was class sharing. It supports sharing of much of the rt.jar contents between all JVM's running on a system, purely by using OS-level virtual memory tricks. The first Java instance to start on a system starts normally, but if there's an existing java instance running on the system it uses the shared rt.jar stuff that's in shared memory.
MVM is so much more than simple class sharing.
Posted by: robogeek on July 27, 2005 at 04:17 PM
robogeek, I think you are missing the point. Does JVM crash? You bet! Do large corporations with mission critical applications use JVM? They DO! We all know software is not perfect, and we take our chances. I will NOT run my mission critical applications on MVM because running on one will increase the possibility of crashing. But I WILL run my desktop applications, utilities, even, dare I say, games, on MVM without hesitation. PRO CHOICE!!
Posted by: walterc on July 28, 2005 at 12:30 AM
