[Sablevm-developer] FW: FW: Java Virtual Machine/Scheme Question

[Brent F. <bre...@xp...>]

Per's reply:

-----Original Message-----
From: Per Bothner [mailto:pe...@bo...] 
Sent: Monday, July 17, 2000 1:07 PM
To: Brent Fulgham
Cc: pe...@bo...
Subject: Re: FW: Java Virtual Machine/Scheme Question


[Feel free to forward this appropriately.]

Brent Fulgham <bre...@xp...> writes:

> After some thought, I eventually gave up on my ill-advised idea of
> hacking the back-end of the MzScheme interpreter (VM) to support
> Java.  I now believe it is better to go the other way (i.e., a
> Scheme implementation in Java), which is of course Kawa.
> 
> One thing I've read in a few places (Kaffe list for one) is that
> the current JVM architecture is not well-suited for implementing
> continuation and closure semantics.  I can't say if this is true
> from personal experience, and I wanted to get your thoughts.

Well, almost no architecture is directly suitable for continuation
and closure semantics.  You have to simulate them using more primitive
constructs - "objects" containing pointers to other objects.  JVM
can do this, just like a raw cpu.  However, there are some things
you cannot do in Java:  You cannot embed one object inside another
(unless one class "extends" another).  You cannot have arrays of objects
(only arrays of object pointers).  You cannot return multiple values,
unless you wrap the in an object etc.

However, these problems can be worked around by allocating extra
objects.  So the JVM may cause some extra object allocation (and
hence garbage collection) than is needed.  The challendge is to
design the calling conventions and APIs to minimize this.

There is no "pointer to function/method" in Java.  You can simulate
this using closure object or reflection, but the latter is quite slow.
So Kawa goes through some hoops because of this.

You can implement continuations by allocating explicit "frame objects",
which some implementations (that do not have the JVM's restrictions)
do anyway, so this need not be major hardship.  The main problem
is that the standard Java calling convention is very different (and
quite faster) that a heap-based calling convention using frame objects.

I did spend soem time recently on an "explicit frame" calling convention
for Kawa for call/cc support.  I made some progress.  My problem is
not figuring how to do it, but figuring out how to keep everything
working together and efficiently will take more time.

Creating a procedure-specific "frame" object is an issue:  Creating
a custom class for each procedure is elegant, but I'm concerned
about the overhead of a large number of trivial classes.

> Could you give any comments on your understanding of the JVM's
> shortcomings in this area, and whether or not the availability of
> such internal hooks might be helpful?  Is it a non-issue, and the
> complaints are really about trivial things?

Well, the problems are trivial if you don't mind allocating an
extra object or two per procedure call.  (Some Scheme implementations
allocate a list for the arguments to every call, which is of course
just as bad or worse.)  If you want to minimize object allocation,
then things are harder.  Inlining can help, for example.
-- 
	--Per Bothner
pe...@bo...   http://www.bothner.com/~per/