Linked by Peter Gerdes on Mon 10th Jan 2005 17:35 UTC
Editorial As a recent ACM Queue article observes the evolution of computer language is toward later and later binding and evaluation. So while one might quibble about the virtues of Java or the CLI (also known as microsoft.net) it seems inevitable that more and more software will be written for or at least compiled to virtual machines. While this trend has many virtues, not the least of which is compatibility, current implementations have several drawbacks. However, by cleverly incorporating these features into the OS, or at least including support for them, we can overcome these limitations and in some cases even turn them into strengths.
Permalink for comment
To read all comments associated with this story, please click here.
VM sharing
by Ian Burrell on Mon 10th Jan 2005 19:00 UTC

There is no need for special hooks in the OS for sharing the code of the JIT between processes. Most modern OSes keep a single copy of the read-only code segment in memory and share it between processes. The JVM and its libraries will be shared.

This doesn't apply to the code produced by the JIT. Instead of having special handling for code produced by the JIT, one solution is to use the existing shared library mechanism. This is done by gcj; it incrementally compiles Java bytecode into .so files. These can then be loaded and shared normally.