Juice [Re: UVM and Microsoft]

[Dwight Hughes]

| From: Michael Korns <mkorns@ix.netcom.com>
| 
| Dwight,
| 
| > After being quite excited about Juice, to the point of wanting
| > to base the entire LispOS on such an approach (not just the LispVM)
| > -- like they have done with Oberon -- I find myself rather 
| > ambivalent about it upon further study. (Don't let this hinder
| > your own research - Juice is truly fascinating and has a *lot* to
| > offer to this project.)
| 
| I just got through looking at everything Juice has. I like it in ways

Just to make sure - have you looked at all the papers on these pages?
Michael Franz  <http://www.ics.uci.edu/~franz/>
Thomas Kistler <http://www.ics.uci.edu/~kistler/>
also there is the Oberon home page:
<http://www-cs.inf.ethz.ch/Oberon.html>

| similar to your own. What I don't understand is how Juice differs from a
| JIT? Suppose we send a compressed Lisp S-expression across the Web,
| uncompress it at the destination and eval it. Assuming the eval compiles
to
| native before running, we have a Juice analogous JIT. Assuming the eval
| compiles to VM pcodes and emulates, we have a Juice-Java hybrid? What am
I
| missing here?

JIT compiles code as it comes to it in its execution sequence (code never
reached is never compiled); execution time for a JIT necessarily always
includes compilation time as well (it is the nature of the beast). There is
a secondary effect on fast cache based systems, since the JIT compiler,
being active along with the executing code (interleaved with it in fact),
soaks up some of the CPU's hardware cache, contending with the executing
code. The Juice approach is to compile *entire* modules upon loading - 
Juice doesn't care to wait to find out if the code will be executed 
(since Oberon is a descendent of Modula, modularity is not a problem);
the idea is that even using their very compact AST representation,
compilation is still an I/O bound process - compilation time is hidden
entirely in the loading process. The Juice compiler then gets out of the
way for the code to run by itself, scoring a second speedup. JITs will
have a problem taking advantage of the loading time to begin operation
since executing a program only partially loaded could have some
*interesting* side-effects, whereas the Juice compiler is just getting
input and generating output, not executing the program or module.

| > The aspects I do not like are: 
| > 1) the compact AST intermediate representation cannot be efficiently
| > interpreted, making porting between architectures rather a pain -
| > native code or nothing basically (of course, we don't have to do it
| > exactly this way)
| 
| I agree completely. See the above Juice-Java hybrid.
| 
| > 2) the native code generated is of rather poor quality (no fault
| > of theirs - they have simply tuned for speed of generation, not
| > optimization).
| 
| Their site claims execution speeds equal or better than Java JIT's. How
do
| we get a verification of their actual code execution speeds versus Java
JIT
| execution speeds?

Don't they have a Juice plugin with demo applets? I believe some of their
papers have some actual numbers also. Don't remember which ones offhand.

-- Dwight