Skip to main content

Consumer JRE & MVM

6 replies [Last post]
christiaan_se
Offline
Joined: 2006-07-13

Hi,
out of curiosity, does the consumer JRE use concepts of the MVM (http://java.sun.com/developer/technicalArticles/Programming/mvm/), or do they simply have goals in common (startup time and small memory footprint), but have a different approach?

kind regards,
Christiaan

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bilal_el_uneis
Offline
Joined: 2006-12-10

i know i asked about this a while ago in a prev thread. i cant remember what response i got, but anyway what surprise me is that M$ has implemented its .net on the same concept of MVM and for the last 7 or so years it has succeeded, i wonder why this is still not implemented and tried in our java world.

i have nothing JQS it is great and all , but why waste time on it when MVM could be run a a process/service like JQS and would allow multiple JAVA applications to run on top of on JVM. this will eliminate both startup and memory issues, also this process can detect .class and .jars making JAVA apps run like any other .exe or .bin file.

Bilal El Uneis

linuxhippy
Offline
Joined: 2004-01-07

The Consumer-JRE does have a "QuickStarter", but I don't know of any other significant faster-startup ir lower-footprint changes that have been made. It does not use concepts from the MVM.

However there have been many other, in my opinion even more important enhancements like the new-written browser-plugin.

lg Clemens

christiaan_se
Offline
Joined: 2006-07-13

Hi Clemens,
I absolutely agree that there have been even more important enhancements. I was just wondering whether next to startup time and download size there also is a focus on scalability (in terms of memory footprint when multiple java applications are running on the same machine, which is a focus point of MVM). Would be quite interesting to our company.

kind regards,
Christiaan

bharathch
Offline
Joined: 2004-02-16

Speaking of the MVM, it seems to have gone the way of the brontosaurus and the dodo. Last I heard, Grzegorz Czajkowski was supposedly working on it at Google, but nothing (public) seems to have come out of it. (Or was it the android VM that came out his work ?)

ga427
Offline
Joined: 2007-05-14

The current approach is to squeeze all of the juice out of the existing approach, reasonably enough. The results so far are impressive from a startup performance perspective, which is the major pain point, generally, IMHO.

Christiaan correctly points out that this ignores memory footprint, and that MVM should help significantly here, even with class data sharing implemented, and (presumably) a re-entrant JVM. Also, startup delay will be completely eliminated, practically speaking, besting even Java 6uN. It may be the case that Java 6uN's startup time will sufficiently fast that few will care.

There is additional work needed for MVM, however - resource consumption - each Java app must not consume excessive resources within a MVM, particularly memory but also CPU, network, JDBC connections etc. See the Resource Consumption JSR, JSR 284, which is still alive and well and led by our good friend Grzegorz Czajkowski at Google. So MVM is still alive, just delayed and out of the spotlight. I would hope that MVM would be available as an option in Java 7 (default off), and not just for JME...

There is a point that MVM users must be aware of: native code that unrecoverably fails. In a MVM context, this means that the JVM and all of its hosted Java applications will ALL fail. Now, practically speaking, this doesn't happen that often (the native code in the JDK is robust), but what about flakey 3rd party code, or code in development that somehow causes unrecoverable native code failures? The solution is multiple MVMs with the flakey code localized in one or more MVMs away from the good code in another MVM (the easy approach, and sufficient for developers, IT). An enhancement is to have an option in MVM to force the questionable code into a separate process, optionally (more work and more overhead for the code in question). To enable MVM for end users by default will require the enhanced approach but that could wait until MVM v1.5.

It would be awfully nice if we could support dynamic migration of applications between MVMs (dynamic load balancing), even between different machines (and hardware architectures, operating environments), but this would require reconstructing of objects with native state, which is best left to MVM v2.0. This would provide application fault tolerance, which is a nice reliability bonus. This would also give us orthogonal persistence (a Java centered OODB), at long last and application resumability.

Glenn

christiaan_se
Offline
Joined: 2006-07-13

Glenn, these are some nice insights. Thanks! Good to hear that MVM is still alive.