[mike_hearn]

In practice big GUI apps like Eclipse are not intended to share a single VM with lots of other things, let alone multiple instances of itself. If people wanted to write tools that did that (i.e. if it was common) then they could, but it's not enforced. For example even if at the Java level you can separate stuff out, native code to handle the GUI framework might not be expecting it.

[throwawayaway]

I know they weren't written to do so obviously but you can see how it's a related example. You can also understand why if it was the sort of thing that could work it would be worthwhile, what with the amount of RAM each of the Eclipse users had devoted to its (in theory duplicated per user) JVM.

I doubt you would even have to go as far as native extensions for GUI before you start running into problems even though the programs are written in managed code.

Can you better explain how in practice Java programs could share a VM in replacing a typical Unix bash environment/userland?

Would they have to use the special IBM JVM? Would bash have to contain grep as a class? e.g.

machine:~$ grep include Source | grep -v 32 | grep -v 16

Reading about "JAR hell" I really don't think it would work very well.

Interestingly in the IBM link provided earlier they load up substantial non GUI servers such as Tomcat, Jetty and JRuby and achieve a startup time that is twice as fast.

They also have hello world:

Hello World Print "HelloWorld" and then sleep

Multi-tenant JVM: 309

Hand-tuned: 73

Default: 63

Improvement with multitenant: 4.2X to 4.9X

Even with this I think a C++ version would eat it for breakfast. It would be interesting to find out what would happen if a Single JVM were loaded on boot, all programs were loaded into that and compare the JVM based Unix on those terms with e.g. Solaris or something.