Embedding VMs

[Marc Wachowitz]

Paul Prescod <papresco@calum.csclub.uwaterloo.ca> wrote:
> Sun's goal was to allow the NEW bytecodes to work in OLD JVM
> implementations. If you don't care about that, you can just create new
> bytecodes

... and be really annoyed as soon as Sun releases another version of
the JVM spec. If you don't care about tracking the official spec closely,
I don't know why you'd want to try it for the first version. If you want
to track it closely, you're left with attributes, since everything else
will clobber the "namespace".

> Anyhow, I would argue for the implementation defined attributes.

If you want something Common Lisp to work efficiently, I'd expect this
to be a big source of complexity. If you only want something similar to
Scheme, perhaps giving up full continuations and tail-call optimization,
or giving up efficiency (e.g. via adding a further indirection for all
calls, or using Henry Backer's trick of explicit CPS calls with unwinding
at stack overflow), it may be a reasonable approach. I'll wish you luck
with it, but I'm interested in an efficiently usable MOP (Common Lisp's or
EuLisp's or something with similar power) and fast multi-arg dispatch and
real multiple inheritance.

> He didn't see the limitations of the JVM as being a
> very big impediment to Kawa's performance.

I'd defer this judgement until Kawa-generated real-world Scheme code
for a wide variety of programming tasks compiles to something competitive
in speed and memory usage with excellent optimized C code. Of course, if
you're merely looking for something faster than e.g. current Python or
Perl or Tcl, the JVM would most likely be sufficient. Again, that's not
what I'm interested in - I can have that already with existing Lisps.

> What you are describing is a system which is backwards compatible with
> the JVM: an extended JVM. I believe that starting from existing JVM
> source is much more efficient than starting from scratch, and that using
> attributes to remain compatible with existing JVMs would be a good idea.

Existing JVM _source_ and freely available ("free" in the GNU or Berkeley
license sense, not just as in "available without payment, non-public source"):
This would mean Kaffee, or did I miss other relevant players in that area?
I don't have the impression that there's already sufficient difficult stuff
in there to be worth basing a Lisp environment on this system layout, instead
of simply reusing some parts which might be really helpful towards that goal.
(Note that any Java-based libraries would be equally available for the JVM-
on-top-of-Lisp approach.) If you add the effort to make such a system perform
well for Lisp-style code, I doubt you'll save much, just the contrary.

> I think that the technical reason for using the JVM is that there are
> millions of JVMs deployed and thousands more every day.

I'm surprised. Do you seriously expect to have everyone of the big guys (Sun,
Microsoft etc.) implement the extensions which you'd like for Lisp? Otherwise,
you can simply forget counting these as platforms supporting your desired
kind of system, as it won't run very fast. People will soon expect something
with similar speed as with excellent JIT compilers from Java, since that will
be what they'll have for a comparison; then, failing there would merely add
another piece to the old "Lisp is slow" myth. Most people won't even listen
to your excuses why a standard JVM isn't so efficient for Lisp, and even less
will understand your explanations. I'd like to avoid that.

-- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>