I actually worked for Sun/Oracle on VM's but on the embedded not hotspot team. The trick is actually simpler and its called MVM, which is something Sun kept avoiding on the desktop/server for some stupid reason but we did do it on mobile and it made startup almost instant.
The trick is to share one VM instance between multiple apps. So when the OS starts you start the VM process and then fork with a lot of the JITted code already in place so you get almost instant startup and reasonable process isolation.
In mobile where there are some restrictions this is very practical. On the desktop/server this gets a bit tricky with bytecode manipulation, classloaders etc. But this is totally doable.
My personal uninformed theory is that Sun or Oracle didn't do this because they didn't care. MVM has two use cases: faster startup/lower overhead on desktops (they don't care about that).
Server efficiency in small scale deployments (which they don't care about either). AFAIK Google did some work on MVM for App Engine Java, but those are just rumors.
> The trick is to share one VM instance between multiple apps. So when the OS starts you start the VM process and then fork with a lot of the JITted code already in place so you get almost instant startup and reasonable process isolation.
Android does this, unless it changed recently. The common parent process is called "Zygote".
MVM relies on the runtime system to enforce security isolation. In a system like Android that allows unrestricted loading of native code, this scheme can't work, since there's no way to get arbitrary native code to play along with the runtime security model.
Personally, I feel much more confident with the kernel enforcing application isolation than I would feel about relying on the Java security model.
As a sibling comment pointed out, Android already does this. To learn (an insane amount of) more detail about how this works, read this article I wrote a while back on how Process Loading on various systems is optimized.
It's not the same thing at all. Android first makes a process template, then takes clippings for each process it wants to run. That's not the same as running different applications in the same process.
The person who worked for Sun/Oracle, the one who first mentioned this technique earlier in this thread, was quite clear that the technique involves loading a single VM and then "fork[ing] with a lot of the JITted code already in place and reasonable process isolation". You are, of course, correct that this is not the same as "running different applications in the same process", but that is not the technique that was described.
> The trick is to share one VM instance between multiple apps. So when the OS starts you start the VM process and then fork with a lot of the JITted code already in place so you get almost instant startup and reasonable process isolation.
FYI that's how we implemented MVM in CDC mobile which isn't necessarily applicable for hotspot.
The MVM RFE for hotspot has been something desktop developers have asked for since JDK 1.2 days. It sort of got sidelined when the JDK started sharing loaded classes (the rt.jar) which is important but not quite MVM. Even the weakest of Android devices is probably more powerful than our "smartphone" targets in terms of heap. Using process isolation was often not an option back then since common OS's at the time (symbian) didn't really have isolation.
HotSpot has something called "Class Data Sharing" these days, in which pre-processed data is mmapped into the VM and shared between VMs as a result. More and more stuff is being put into the AppCDS files with the result that the VM has to do less and less work to start up. The jigsaw work also includes stuff like this via the jimage file format.
I don't think this is a significant issue because it's a one time cost. It could be done at browser startup. Even for a cold start, Hotspot and V8 are comparable.
$ time java com.Hello
real 0m0.096s
user 0m0.103s
sys 0m0.013s
$ time node /tmp/hello.js
real 0m0.073s
user 0m0.067s
sys 0m0.007s
