Virtual machines

[James P White]

At 01:04 AM 5/22/97 +0000, Terrence W. Zellers wrote:
>   IMO it ***MUST*** be capable of fully virtualizing itself in 
>execution, not just emulation.   This means it must have a paging
>prefix algorithm, the ability to intercept any instructions which
>deals with "real" rather than "virtual" hardware,  and the
>interception and determination of any illegal program state (invalid
>opcode, invalid address, etc).   Admittedly this is not trivial but it
>buys the ability to completely virtualize a process as if it were
>running on "real" hardware.   

The JVM does provide for virtual implementations of all system resources
(the "real" hardware).

It does not provide for virtual implementations of memory.  I'm pretty sure
though that appropriate class design makes that unnecessary, as in the
system resource classes.

In the same vein, the JVM does not provide for redirection of exceptions,
other than by virtualizing the class.  The JVM does have a full complement
of exceptions for dealing with all sorts of invalid machine state, there is
no general mechanism for using trapping/emulation to resolve those
exceptions because Java does not provide for resuming from an exception.

The JNI (Java Native Interface) does provide for creating additional JVMs,
but the level of control is kind of boring (just the initialization parameters).

Extensions to the java.lang.Runtime, java.lang.System, or
java.lang.ThreadGroup should be able to fill in the holes, which are memory
management and thread policies (although ThreadGroup appears to have most,
if not all, that is needed).

As an O-O machine "to the metal", the JVM does not need to virtualize
memory-mapped hardware, which is what much of the IBM VM architecture was
about.  In Java, the idea is to design classes with good interfaces.  Those
classes can then be virtualized as desired.

The shortcomings in the JVM are that some essential implementation issues
are hidden.  A good example is the JVM stack.  Typical implementations
(including the JDK) use discontiguous, dynamically allocated stacks.
Exactly what is needed to provide for continuations.  Unfortunately the JVM
does not offer machine state as an object, other than as a thread.  A
suitable JVM implementation could solve this through a native class (which
of course would be virtualizable).  This same technique can be aimed at most
deficiencies you want to name, including making arbitrary extensions to the
VM (different exception handling, or ???).

While I understand that it is easy to hate the JVM, I'm pretty sure it is
actually extremely close to being sufficient as a LispVM.

Jim
-----------------------------------------------------------------------
James P. White                        Netscape DevEdge Champion for IFC
Director of Technology Adventure Online Gaming http://www.gameworld.com
Developers of Gameworld -- Live Action Role-Playing and Strategic Games
jim@pagesmiths.com        Pagesmiths' home is http://www.pagesmiths.com