Virtual Machines

[Arthur A. Gleckler]

Marcus G. Daniels writes:
|  >>>>> "AG" == Arthur A Gleckler <arthur@martigny.ai.mit.edu> writes:
|  
|  KM> So I say drop this whole VM discussion.
|  
|  AG> Having to recompile your code when switching systems is not the
|  AG> problem.  The real problem is having to change your program to fit
|  AG> the new system.  There's no need to build an interpreted VM or a
|  AG> VM with a JIT compiler for Lisp portability, and the drawback of
|  AG> using such a system is potentially dramatically reduced
|  AG> performance.
|  
|  One feature of Java is the promise of being able to do static,
|  optimizing compilation ahead of time, and efficiently communicating
|  and executing the result on a remote JVM.
|  
|  Today, this disease of needing to modify a program to fit a
|  slightly-different system is not so difficult to treat.  Whether that
|  means GNU autoconf, the proliferation of free operating systems like
|  Linux and BSD, or a portable Lisp system like MIT Scheme or CLISP, the
|  business of making programs portable is getting easier.
|  
|  Sorry if I misunderstand, but it seems like you are also saying that
|  static, optimizing recompiliation isn't sufficiently expensive to
|  justify moving around virtual object code.  That conclusion isn't
|  clear to me yet.  Could someone please convince me?

I suppose it depends on the application.  If the program is run many
times per machine, then the time taken for recompilation isn't much of
an issue, as long as latency isn't a concern.  If the program is
delivered and run once or only a few times, then compiling from source
instead of from byte codes might be a burden worth avoiding.

In general, though, the two aren't mutually exclusive.  One could
provide a VM for programs intended to be shipped around and run just a
few times, and provide an API for longer-lived, more traditional
programs.

What gives Java the important part of its portability is the fact that
it provides a set of standard class libraries for dealing with
operating system services, user interfaces, etc.  It's not the fact
that its code is compiled to a universal virtual machine.  That has
more to do with increasing code density and discouraging reverse
engineering than with portability.