Gilbert asked a question in JustJOS that I end up answering a lot. The question is:
Why does JOS need a Multi-Process JVM?
I will be adding to this list over time as I remember all of the reasons:
- A good reason why you want ONE Multi-Process JVM as apposed to many JVMs is MemoryConsumption. If you have multiple JVMs, then every time you create a new JVM process, the base classes are copied into memory again. This is completely unnecessary with a single JVM smart enough to keep seperate processes seperate within itself. With this type of VM, you can load a single version of a class's bytecodes into memory once and share the bytecodes amongst all of the processes. Each process will need its own stack and static variables (otherwise they would conflict with each other) but bytecodes can be shared. If one process needs one version of a class and another process needs an old version of a class, then both classes will need to have their bytecodes loaded seperately into memory. Thus, the JOS runtime system can save gobs of memory over another OS with multiple JVM's running the same processes. This is an inherent benefit of having a Java Operating System rather than just the Java Platform.
- Against popular opinion, multiple processes cannot be adequately or safely implemented inside a single normal JVM with simple ClassLoader tricks. Many have tried, and many have failed. To a certain extent, this can work for most applications that do not create their own ClassLoaders or SecurityManagers. However, using this approach would limit JOS's ability to support the entire Java Platform. We would only be able to support a subset due to the technical limitations of this approach. I have been lurking for quite a while on the JavaDesktop mailing list where many of those who have tried this technique discussed the problems with this approach. Among these are LukeGorrie of the Echidna project. Not all Java applications work under Echidna, and if JOS were to use this approach, we would be restricted in the same manner.
* So if neither of these approaches is best, what can we do?*
We can build multi-process support into the base JVM such that processes think they are still in their own JVM, but yet when classes are loaded, bytecodes of common classes can be shared accross processes. No ClassLoader tricks are required at the bytecode level.
(One way of implementing this inside the JVM is to use some PrimordialClassLoader tricks, but these do not keep us from being able to be 100% Java compatible.)
- AveryRegier (9 April 1999)
See Also: [ PrimordialClassLoader ] [ MemoryConsumption ]
|
Content of these pages are owned and copyrighted by the poster.
|
|
Hosted by:
|
|