[Sablevm-developer] [Fwd: RE: [Sablevm-user] About closures...]

[Etienne M. G. <eg...@j-...>]

For the record;-)

-------- Original Message --------
Subject: RE: [Sablevm-user] About closures...
Date: Tue, 18 Jul 2000 13:21:46 -0700
From: Brent Fulgham <bre...@xp...>
To: "Etienne M. Gagnon" <eg...@j-...>

> Brent Fulgham wrote:
> > These sound like excellent ideas.  The only other thing 
> > that might be useful would be a "UseSameFrame" bytecode 
> > for help with tail-recursive situations.  I.e., a Scheme 
> > compiler for SableVM would be able to provide the JVM with
> > the "UseSameFrame" for a tail-recursive functions to
> > save stack space and convert the 'recursive' function into 
> > an interation.
> 
> You know, this "UseSameFrame" bytecode would be almost trivial to
> implement.  But more importantly, it would be very easy to extend the
> verifier to check that it is correctly used:

[ ... snip explanation ... ]

I've started reading up on the Java VM (I am not familiar with
its internals) last night.  I notice that its instruction set
is mapped over 8-bit values, so there are only 256 instructions
available.  I also read that most data types have their own bytecodes
for operations, which must use up quite a few bytecodes.

Is there room for three new bytecodes (UseSameFrame, BeginContinuation,
UseContinuation)?  I'm a bit worried :-)

In fact, I wonder if the JVM could identify tail-recursion on its
own and handle it behind-the-scenes.  It seems that the bytecode-level
commands might be too simple to allow for easy recognition.  I don't
know.

It seems to me that we are always better of avoiding new bytecodes
(or rather, any change in the JVM's API) if possible so that we are
fully compliant with the "Java" specification.  Non-standard additions
mean people are not likely to use them, and they are therefore less
likely to become part of the standard system.

> Of course, this "UseSameFrame" wouldn't be available to 
> native methods.  Or, to be precise:
>  - A bytecode method IS ALLOWED to invoke native methods through the
> "UseSameFrame" bytecode.
>  - A native methods CANNOT is limited to the current JNI interface,
> which desn't export a similar functionality.
> 

Agreed...

> This would be a good thing, as:
>  - The native code uses the normal "C" stack, which is (or can be)
> different from the interpreter stack.  The native language can already
> have its own mechanisms to "reuse" the current stack frame, 
> so exporting the functionality from the VM is not that important.

Right.  We might even mess things up if we don't fully understand
the underlying system's handling of this.

>  - The VM stack contains frame(s) of "Local" references, 
> which handling would become a nightmare if the "UseSameFrame"
> functionality was exported.
>
 
Yes.  And it adds a lot of complexity we don't want.  Generally,
tail-recursive cases will be occurring in the "runtime" code
(i.e., non-native code) as parts of algorithms, etc.  Especially
under Lisp-ish systems.  So I don't see that as being a big
problem.  If someone wants to write a Java class (e.g.) that
wraps some set of native routines, then uses these classes as
part of a tail-recursive procedure, I don't know that we want to
give it the "UseSameFrame" special treatment.

> PS: You may use these ideas as you see fit, but I would be 
> grateful that you gave me credit.

Of course!  I don't plan on doing anything with this information
outside of SableVM, should we determine that this was beneficial
to the overall goal of the VM.

> PPS: It might be interesting, at some point, and if our projects go
> along, to write some joint paper(s);-)

Absolutely!  There are several obvious topics that could be 
written up (the tail-recursion, especially if done inside the VM 
without need for special bytecodes; success in implementing some
existing functional programming experiment on the JVM, as in the 
Haskell-on-JVM done by the Wakeling '98 paper; or just about any
new aspect of the VM).

Of course, it's been a couple of years since I last wrote a journal
article (and that was in my former career as an Environmental
Engineer).  It would be nice to be published again for studying
things I'm interested in.  :-)

Regards,

-Brent