17 Feb 2001,   xxxxx@xxxxx   -- see also # 4187333.

java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

The java runtime right now is pretty inefficient when it comes to
having multiple runtimes.

You can take the smallest class, run it, and it will take up
X megs of RAM. And the next JVM running it will take up another X megs.
and a third JVM will take up another X megs.
[trivial little program follows below.]

I'm happy to see that 'X' has decreased, from 12 megs for JDK1.2, to
about 6 megs for JDK1.3
But in principle, I would think it could be better still.

If you want java programs to be used as commonly as C programs,
you need to make the runtime similarly efficient about sharing common objects.

One of the reasons C is so memory-efficient is that it has a shared
"libc". The java runtime seems to lack that. I don't think the
common system classes are being shared at all. I guess they're
all being loaded in from "rt.jar" separately.

What the runtime needs is a pre-expanded set of instances of the
standard classes, that can be shared in a .so with additional runtimes.
[Or something similar anyway. Hopefully, you guys can think of something that
 would deliver a similar level of memory sharing]

Here's a trivial class to demonstrate the problem:

public class test {
        public static void main(String args[]){
                System.out.println("Sleeping...");
                try {
                Thread.sleep(10000);
                } catch(Exception err){ }
                System.out.println("Done");
        }
}


Each invocation in parallel, takes the same amount of additional memory as the
initial jvm invocation does.
6 megs each time, for a 542-byte class that doesnt even attempt to open a
graphics window.

This kind of memory footprint makes it impractical to write small java
utilities. If everyone on a system were to use them, they would quickly swallow
available RAM.
(Review ID: 117186) 
======================================================================

none
======================================================================

  xxxxx@xxxxx   2001-10-12
In progress.

------------------------------------------------------------------

Class data sharing (CDS) has been introduced in the 1.5 release as the
first step toward addressing this problem. The CDS code was originally
developed by Apple Computer, Inc. during their port of the Java
HotSpot VM to Mac OS X and was further developed within Sun primarily
by   xxxxx@xxxxx  .

CDS is supported on platforms where the Java HotSpot Client VM is the
default, except for Windows 95/98/ME. When the JRE is installed on
supported platforms using the Sun provided installer, the installer
loads a set of classes from the system jar file into a private
internal representation, and dumps that representation to a file,
called a "shared archive". If the Sun JRE installer is not being used,
the shared archive can be created manually, as is explained in the
Java HotSpot VM documentation (linked to from the 1.5.0 release
notes). During subsequent JVM invocations, the shared archive is
memory-mapped in, saving the cost of loading those classes and
allowing much of the JVM's metadata for these classes to be shared
among multiple JVM processes.

The primary motivation for including CDS in the 1.5 release is the
decrease in startup time it provides. CDS produces better results for
smaller applications because it eliminates a fixed cost: that of
loading certain core classes. The smaller the application relative to
the number of core classes it uses, the larger the saved fraction of
startup time.

The footprint cost of new JVM instances has been reduced in two ways.
First, a portion of the shared archive, currently between five and six
megabytes, is mapped read-only and therefore shared among multiple JVM
processes. Previously this data was replicated in each JVM instance.
Second, less data is loaded out of the shared archive because the
metadata for unused methods remains completely untouched as opposed to
being created and processed during class loading. These savings allow
more applications to be run concurrently on the same machine. However,
on some operating systems (in particular, Windows), the perceived
footprint of the process may increase, because a larger number of
pages are being mapped in to the process's address space. Reducing
footprint, including perceived footprint, remains a high priority and
work is ongoing in this area.

The class data sharing work is a step toward reducing the startup time
and footprint of Java applications without sacrificing stability or
compatibility. In the future we plan to share and cache other data in
the archive and extend its functionality to application-level classes
to more significantly improve startup performance for larger
applications.

  xxxxx@xxxxx   2004-01-23

This is indeed a VERY important problem. It seems that when 
an application, how simple it may be, uses Swing, memory 
consumption rises to about 13 MB. Every other Swing 
application, how small it may be, takes this amount again. 
I can think of two solutions myself: 
1. Create a easy to use _standard_ mechanism, for invoking 
multiple apps in the same JVM, each with a different class-
loader (This would only be an advantage if classloaders do 
share class-code more efficiently than instances of JVMs, I 
don't know if that's the case, if not; work on that too :-
) ). This could be the default behaviour of the 'java' 
command.
2. Improve memory sharing between JVMs. (like advised by 
the poster of the RFE).

This are ofcourse very difficult issues to resolve, and 
probably many aspects, like security and naming-clashes are 
addressed, but it's very important, because;
It must be possible to run multiple swing apps without 
wasting all memory. Much more users will be able to use 
Java apps like native apps then. (After all, most users 
only have a limited amount of RAM available.)

Sharing is very important to solve memory usage problem

In my humble opinion, this bug/RFE (a matter of taste), is
closely related to the following bug/RFE ids:

4187333 (38 votes)
4287407 ( 2 votes)
4353002 ( 3 votes, closed as a duplicate of 4287407)
<this one> (56 votes)
4511554 ( 3 votes)

Sums up as 102 votes, why not keep just one of the items as
open and put all votes on that one?

Looking at 4287407 it seemed to be scheduled for "Merlin"
which I think became released as J2SE SDK 1.4.0 but I can
not se that one as "solved" in the 1.4.0 release notes.

This is part of the general memory-usage disaster, se
item 4466510 which now has 675 votes, being the third most
popular open RFE.

How much of the memory problem is an implementation "only"
issue. Is there any language or JVM spec changes needed? Do
anyone know of other JVM implementations (IBM, JRockit,
...) that is more lean on memory than Sun's JVM?

Kind regards

Tomas

When provisions are being made to let multiple apps run in 
the same JVM, maybe it's also a good idea to create 
a 'machine global context' object, in which applications 
explicitly willing to communicate or share data with other 
applications, can place 'very-global' objects, like certain 
singletons with machine-scope (or greater), and create all 
kind of communication objects, for communications between 
apps which are aware of certain services of other apps 
and/or the JRE. Ofcourse on most systems this 
communication aspect can be realised using rmi or maybe nio, 
but for these you need network and file-support, and seem to 
be more heavy-weight. It would also enable applications to 
see if there's another instance of it already running and let 
the second instance execute in a different way, possibly by 
sending a signal to the first instance to open a new window 
or something. (Like some web-browsers and popular office-
apps do.) This 'single-app' feature was requested by others in 
some RFE (4317487). 
Maybe RMI or NIO would be able to solve all this in EVERY 
situation. But I could think of some systems without file or 
network support. Anyway, it's great that work is being done 
on the memory problems!

AFAIK this is already in MacOS X' JVM. Rip it off, please ;)

To make this work security-wise it would be a good idea to 
lift the idea of 'Firewall Classloaders' from Iona's Orbix 
application server. this would allow sharing of the JVM while 
still maintaining a reasonable level of security.
http://www.theserverside.com/resources/article.jsp?
l=AdvancedClassLoading
Bob B.

And you managed to screw up agian. We NEEEEEDED this in 
Mantis. You said, Merlin, than Hopper, than Mantis and now 
Tiger?!!!!! In first half of 2004!!!!!!???? Two small Swing apps 
and 40 M is gone!!!!! And we should all write client side Java? 
And IBM was wrong with SWT?! And we should not look at 
.NET? There are some very good and loyal 
customers/programmers that are with you from very begining, 
and are getting ridiculed all the time becaouse of yours 
promisses and failure to do something that is fairly technicaly 
simple task (Apple has done it).  Is anyone listening???? You 
just made a crucial dissaster that will be impossible to recover 
from. In one year everybody can port everything they got to 
.Net and actually become concurent with rest of the world. 
There is no Java without client side Java, I can't beleive that 
you can't understand that. I'm starting to lose my faith in you 
guys, and if I'm considering switching to Msft than something 
is very wrong indeed cose I managed to avoid them for 10 
years. 

Please clarify this becuse it seems contradictory.

Is the complaint against the JVMs memory allocation, or the
JVMs memory usage?  If its against memory usage then it
should specify a platform.  The c statements you made infer
its against the JVMs memory usage and that the JVMs should
share a common DLL for example on windows.

What tools did you use to measure the memory footprint of
the JVM, I hope it was not the 'taskmanager.'

The JVM will always and should always seperate its memory
allocations, but I dont see a problem with them sharing a
dynamic link to a DLL.  Of course they would all crash
together right?

If this feature is implemented, it is critical that the
shared memory pages be marked read-only for security reasons.  

http://www.javalobby.org/thread.jsp?forum=61&thread=7832

There's a rumour on JavaLobby that this feature won't make
it for 1.5. Could someone from inside Sun please comment on
that? 
1.5 is IMHO Sun's last chance to get at least some Java on
the desktop.

Why are we waiting it's getting irritating...

Guys, if you don't get this by 1.5, then you can kiss java
goodbye on the desktop. C# and WinForms on Windows and Gtk#
for linux kick Java's ass for GUI apps  _TODAY_ by
magnitudes of order.  TRY those technologies out and observe
how friendly and efficient they are for both the user and
developer.  Hopefully you people might get a much needed
heavy dose of reality.  I am personally fed up wtih the
Sun's snotty evangelism which woefully falls short of java's
capabilities on the desktop. It's currently the most
in-efficient and memory-hogging  language for building
desktop applications. Users just hate to work with Java
client applications. Developers hate building them. Only a
certain band of fanatic zealots whose futures are
inextricably entwined with the future of Swing claim otherwise.

Generics and fancy foreach's _should_ have been dropped in
favour of much-needed performance enhancements if you are
unable to justify investment in Java. If you guys can't do
it  then open-source Java - the community will do it for you. 

Java is close to being dead on the desktop. IBM's eclipse
with SWT/JFace is helping to revive it but only just.  You
guys seem to have a death-wish for Java on the desktop with
your sustained negligence and posturing. Postponing
essential features will help transform this death-wish into
reality.

Desktop Java is Dead! May the Sun forever shine on desktop java!

I guess its time to look forward to C# and Mono...

http://www.javalobby.org/thread.jsp?
forum=61&thread=7832&start=0&msRange=15

This has to be the most important feature missing from the
JVM. After all, isn't it supposed to be a 'virtual machine'?
Surely it is time to put to bed all of the problems
associated with not having it (start-up times, memory
overhead leading to excessive swapping...)!

Mac OSX does this already, and it works really well - the person 
who claims Desktop Java is dead should have a look at the OSX 
version of Swing. It's hardware accellerated, and almost 
indistinguishable in performance terms from the native GUI. SWT, 
on the other hand, runs like a dog on OSX (possibly because it's a 
very crude port) and forces everything to look like Windows. I 
agree that a LOT of work needs to be done to make Java viable on 
the Desktop - but is you want an idea what kind of things need to be 
done take a look at OSX. The swing implementation is fast and 
smooth (apart from a couple of really irritating bugs), or if you 
prefer you can use the native GUI library fairly transparently from 
java too. With many OSX apps the user wouldn't be aware they 
were written in Java unless they were a programmer and rooted 
around inside the app to have a look. Another thing that Apple 
seem to have got right, that's appalling on Windows is launching of 
java apps - its really awkward and kludgy on windows - these 
things are important for the User experience, which is something I 
really don't think Sun understands very well. 

If Java is to have any chance on the desktop against
c#/.Net, then a shared VM is a necessity.  MacOSX has a
shared VM. Why not ask Steve Jobs to give you the code in
exchange for a decent port of StarOffice for OS X ;-)

Seriously, Microsoft is going to use their desktop dominance
with C#/.Net to drive it into the server space, just like
they did with Winblows.  A someone else posted here, get a
shared Vm into Tiger of kiss client-side Java apps goodbye
forever, then watch M$ encroach on the server side...

This is extremely important, not only at the desktop level, but 
at the server level.  We are a WPP (Web Presence Provider) 
and want to provide J2EE Hosting solutions, which we want to 
include "seperate VM" in.  This may blur the lines of 
seperateness, but I still think it is important that this be 
done, because when you host several 100 sites, you don't 
want to have to buy a box for each site!

A shared VM is necessary not only to make Java Apps more 
memory efficient but also to increase Java share of the client 
side market. .NET is gaining ground everyday. In my 
Company, the management, previously commited to Java for 
client side, are considering switching to .NETside becasue our 
users need faster apps, customizability of Swing 
notwithstanding!!!

Oh, yes!  Don't know why this wasn't a part of the original
design.  It gets my vote.

It'd also be good if the VM cached compiled code.

There's a somewhat related RFE at 4621943 that'd at least 
allow running JVMs to redistribute free memory among 
themselves when needed

In a recent Java Live dialog [1], Neal Gafter states that VM 
sharing will not be included in J2SE 1.5.

[1]
http://developer.java.sun.com/developer/community/chat/Jav
aLive/2003/jl0729.html

Much needed feature for a satisfying end user experience.

This should be a very high priority.  It would solve many
problems, and enhance java acceptance immeasurably.

This is super irritating. Sun has known about the issues for 
years now. WE NEED A SHARED VM!!!

sun wake up to .net.

I know it is easire to say than doing it....But it is very
important for the client side java development. I do not
know about other OS. but for windows as long as the
following are met in one or the other way, it will be tough
for a client with restricted memory to run multiple
applications. 
1. Have a java dameon that runs as a nt service all the
time. The system class loader should have loaded all the
runtime classes.
2. Each java application that is being started can start
another child process which can be registered with the
master vm. The child process could have their own security
manager, class loader and run in their own context. 
3. When an application is closed the respective child
process can send a signal back to the master vm saying that
it is safe to kill child process. 
4. This way we can prevent error in one application crashing
other applications. 
5. To claim java as a platform [esp in desktop] only the
above makes sense to me. 

You can see how important to Java this is by checking out
the Java Start Button, powered by the netx JNLP client
library.  This runs Web Start apps in a single JVM and you
can see what a huge difference it makes to startup time and
memory use / app:  http://jnlp.sourceforge.net/netx/start.html

The reason Apple can do it so much better is because their
OS and graphics APIs are so much cleaner and easier than
Windows.  Making a shared-VM on windows would be much harder
because of all the bugs and weird limiting APIs left over
from the 1980s Windows and DOS.  In fact, we probably won't
EVER get a shared-VM on Windows if for no reason than
liability (applet destoys computer due to bug in VM sharing;
Sun gets sued).

but why not on Linux/Solaris at least?  Can you imagine a
JVM loading with jKDE on startup and then each app starts
istantly with <1M per app for the GUI?  That's a gold mine.
 I just checked into Qt and wxWindows and the like; they all
suck compared to Java+Swing except for startup time and
memory use.

Process isolation (crash-proofing) or VM sharing (memory 
reduction.)  Pick one.

As much as I dislike Windows, I don't believe the problem is 
truly *that* intractable -- at least large parts of it.

Part of what Apple has done is place significant parts of rt.jar 
(e.g. Swing) in shared memory.  If rt.jar was compiled to 
native ahead of time or all JVMs JIT'ed it into a share memory 
space (perhaps leading to more synchronization, thus the 
ahead of time suggestion), that would seem to be a huge 
savings.  This is really just analogous to native processes 
sharing code (ala DLL's / .so's) across processes.

This is critical to Java as a platform, not only on the
desktop but also on the server.

I am sorry to say this, but in my opinion this is a non
issue. Consider these points:

a) Throwing hardware (RAM - who has not 256 MB or more in
their PC these days?) at the problem solves it. Faster
hardware in general solves it.

b) No one runs 1, 2, 3 Java programs at the same time, if
they do, the additional overhead of roughly 10 MB per JVM is
negligable because of a).

c) Increasing the complexity of the JVM to allow for this
and all the things requested here is a serious effort, it
will touch much code and as such introduce many bugs and
have a heavy negative impact on maintainability, portability
and stability.

This request is unreasonable and misleading, it tries to
connect the problem (Java being unpopular, slow, whatever)
with the wrong cause (memory consumption of the JVM and
possibly slow startup time).

Sun is right on sitting this out since 2001 (because time
works for them, as in performance progress and PC minimal
requirements ever increasing). Please consider removing your
votes from this item, it is irrelevant.

My personal opinion is that ease of programming (rather the
lack of the same) in the common Java APIs is a much bigger
issue.

to canhuth 
 
a) yes, let's sell out programs with special hardware to run it. Or wait 
for 2008 when everybody will have over 1 Ghz and 1 GB memory 
 
b) and why noone runs 1,2,3 Java programs at the same time? Java is 
all purpose language, there should be more clients written in it. See 
why folks from Morpheus use "new engine" in 3.0 (2.0 was Swing). 
Startup + memory 
btw. I do run Columba and NetBeans, and will probably run Glow when 
it is finished. 
 
c) maybe. Who can tell, if it's not seen yet? However, Aplle JMV sure 
doesn't look like is suffering too much from those problems. And 
MVM-2 from Sun's Barcelona project looks like even more promissing 
tehnology. 
 
Java suffers on the client side. A lot. Main reasons that any serious 
client developer (targeting few millions clients) will exclude it when 
choosig tehnology are: startup, memory, JRE download size. Sorry, 
those are the facts. After all, memory + startup problems on vaious 
bug reports and requests have, what, like over 2500 votes. And are 
combined the most popular request. Why do you think everyone 
should remove their votes, just becouse you said so?  

to filipsel

I said "please consider to" and did so in the light of this
issue not being existent or at least not as relevant as many
people seem to think it is.

In my opinion you mistake developer machine requirements
with that of end user machine requirements. Both are not the
same though, esp. when you use the bloated powertools like
JBuilder, Netbeans, etc.

Consider your own Java programs and be honest about
it...what are their CPU and RAM requirements? Would the user
really notice a change in memory footprint of the JVM itself
with your application? And what other Java application would
he run at the same time as yours anyway to make the shared
JVM come into play in the first place? Don't you overrate
the number of popular-enough Java applications a little?
(When considering these questions keep in mind that the user
has different usage patterns as the developer. Of course the
Java developer uses more than a single Java application
often enough. But these Java developers have respective
hardware at their disposal anyway. And the shared JVM
feature is meant for the user, not the developer, is it?)

As I said, I think the bigger problem lies in Java API
programming getting harder and harder all the time. Mr.
Bloch said so somewhere in an interview, but I am not yet
convinced Sun engineers feel the same way about it as Mr.
Bloch. Maybe more hands-on project work would open eyes. :)

to canhuth,
>Don't you overrate the number of popular-enough Java
applications a little?
exactly!  why do you think there are'nt many
"popular-enough" Java applications in the first place? 
would'nt slow startup time and huge memory consumption be
part of the reason?

to sun,
why not give us a choice?  -Xsharedvm or something on the
command line would do.  i might not be totally reliable and
bug free and i may never run my mission-critical server app
on it but for client programs, shared vm is an ABSOLUTE must!

Unfortunately according to the Chat transcript: New Java
Programming Language Features in J2SE 1.5, it says that VM
Sharing will NOT make it into tiger.

dynamite: Is virtual machine sharing going to make it into
Tiger?

Neal Gafter: Unfortunately, no, because of schedule
constraints. Even if it were included, it would be a trivial
implementation that doesn't actually share, but rather forks
off a new VM per isolate.

http://developer.java.sun.com/developer/community/chat/JavaLive/2003/jl0729.html

Why can't core libraries, e.g. rt.jar, be JIT'ed to a high-
degree of optimization into shared, read-only memory pages?  
For that matter, why not have these libraries pre-compiled?

Surely having all of rt.jar, etc, handled in this way would 
significantly reduce memory usage and second JVM load time.  
Isn't this what Apple has already done in part for Swing?

Reducing class loading and initialization of JVM processes 
(after the first) to just the static initializers therein would 
appear to be huge boon and does not seem as insurmountable 
as broader sharing.

Without JVM sharing it's like starting a new windows-session 
for each application you wan't to run!! This is not the way to 
do things. Let a multiuser JVM load on windows startup and 
that way (hopefully) java-apps will only use memory for what 
the app allocates + some overhead.

Please get the JVM sharing done, it is more important than all 
1.5 changes combined.

Do put all available ressources on that !

Please Sun consider including this in the Tiger 1.5 release in some 
form. VM Sharing and reducing startup overhead and memory 
consumption would without doubt have tremendous positive effect 
on Java desktop application development.

This explains why my computer gets slower and slower 
eveytime I run my Java apps not to mention the poor startup 
time. Hope this fixed soon.

I cannot think of any problem with Java more pressing than
this one.  Having the java internals started as shared
libraries would kill off the biggest impediment to
acceptance of Java on the desktop.

Come on Sun - if this were an open source language, this
issue would be solved by now 

Olivier

SUN really sucks !

This bug was opened early 2001. The consideration 
SUN gives to the bug parade where this one ranks five 
is impressive. Give your opinion if you wish but we 
don't really care !

I agree that versus .NET we need more weapons. I 
also see at work application servers which will host 
some tens of J2EE applications. When you have 2 
instances per application (presentation/business) 
plus clustering this is a lot of VMs.

This is why we need this RFE to be FIXED. Put men 
and money in this CRITICAL thing. This works on a 
Mac !! Why not under windows, linux or solaris ?

Search on SUN site for comments 1.5. I have already 
seen transcripts telling that we would have to wait a 
little bit longer? 1.6, 1.7... in 2.0 maybe.

http://java.sun.com/j2se/1.5/index.jsp

The best you can do is to yell at SUN in the next 
JavaOne and to throw your 3 bugs in the bug parade 
for this bug

Maybe one day SUN will understand. I just hope this 
will not be too late.

Sorry, I have to leave. It's time to prepare my .NET 
certification. Who knows what the future will be ? I have 
to be ready.

to canhuth,

most of the things you said might apply on your specific
case, but not completely on mine:

true, lots of RAM solves the amount swapping... I have now
1.5GB and I rarely go over it... so that's cool

I am running JBoss, IntelliJ, DBVisualizer (or Squirrel
SQL), Tomcat, Poseidon and MagicDraw, all 100% java apps 
, and all of this on Linux on which the JVM is slower than
on Windows (even with the RH9 NPTL)

all these apps fit in the RAM I have, so that not really a
problem, the real issue is that whenever I try to run an
Ant/Maven task a new VM is instantiated, I am a professional
developer and start a new VM 1000x a day... and I am waiting
avg 3secs per startup, that's 3000sec = almost one hour
(each day)

I don't mind resting my eyes 1 hour a day extra, but I do
mind when I need to stop after 3 secs, and this 1000x, you
get my point

for Maven there is a plugin that allows this kind of shared
environment (only to run Maven goals) and there the startup
 is much better


this RFE would definately be a very welcome improvement,
MacOSX is looking more and more attractive to me (not only
because of this RFE) - btw, Apple shared their code with Sun
for this shared VM implementation

and to those claiming to switch to .NET etc... (a lot of
blabla.. I don't buy that): good luck, you'll need it with
the amount of bugs on that platform :-)

> all these apps fit in the RAM I have, so that not really a 
> problem, the real issue is that whenever I try to run an 
> Ant/Maven task a new VM is instantiated, I am a 
> professional developer and start a new VM 1000x a day...  
> and I am waiting avg 3secs per startup, that's 3000sec =  
> almost one hour (each day) 
 
1000x a day == 125x an hour == 2 mins per run 
 
no development 
no lunch 
no cig breaks 
 
hahahahaha 

Great work! Thanks guys!

After three years, finally a good step towards the solution.
It has been a long time... 

Congrats! After reading the eval description, I still have
one question: does the shared portion include
HotSpot-optimized classes, or will every JVM still need to
reoptimize the code?

Good job guys.
Thank you.

Good work guys!
Yes indeed a big step in the right direction!

Thank you guys for that one.Looking forward to improved versions and 
hopping you will be brave enough to bring us MVM2 and isolates in 
1.6 so we can all finaly forget startup and overhead penalties.  
 
Good, good work. 

Great news! Please make every effort you can to make this
thing rock! Decreasing memory usage and start up times got
to be the most important things that need to be done to get
that final 'oomph' for the java platform

Good, good and good job. Thanks guys
We are now impatient to play with it in a new version of 
the early release.

Thank  you!!!

Thank you very much for finally fixing (at least to some
point) this.
What about the hotspot/optimized code? Is the 'shared
archive' compiled ahead of time? If this is the case, could
this be used for other, user supplied archive, too? :-))

Patric

I installed 1.5beta on windows xp with its installer. I can
not see any changes in memory foot print. Do I have to
activate something?

If you're looking at the memory usage of each JVM it
probably won't be reported any differently.  Instead look at
total system memory.

I've installed j2re 1.5 b1 on win xp. To get my app work at
all with -Xshare:on I had to rebuild the shared classes with
java -Xshare:dump.
But starting 5 instances of my app with -Xshare:on uses even
more total system memory (140MB) than starting it with
-Xshare:off (115MB).  What's wrong here?

"The MVM achieves improved scalability through an aggressive application of its main design principle: transparently share as much of the runtime as possible among applications and replicate only the part of the runtime system that depends on an application state. All of the known APIs and mechanisms of the Java programming language are available to applications. The end result is that one cannot tell if an application is running as an isolate on MVM or on a JVM of its own, barring a faster start-up and lower memory footprint. [...] The Project Barcelona team has been collaborating with a group at Sun to build a virtual machine for cell phone devices in an attempt to productize the MVM for the Connected Limited Device Configuration (CLDC). [...] The MVM supported multiple instances of the J2EE 1.3.1 Reference Implementation through an efficient implementation of isolates, thus, substantially increasing scalability, reducing memory footprint, and server startup time when compared with the Java HotSpot Virtual Machine. This was achieved without changing server code and with no loss of performance. [...] Productizing of the MVM itself in the Java 2 Platform, Standard Edition, (J2SE) space is under consideration, but no decisions have yet been made" [1].

[1]
http://java.sun.com/developer/technicalArticles/Programming/mvm/

The above comment is informational.  I hope that the J2SE platform will eventually incorporate MVM technology.