[plt-scheme] 301.4

MzScheme and MrEd are now version 301.4 in the SVN repository trunk.


The just-in-time compiler:

MzScheme (non-3m) now includes a just-in-time native-code compiler for
i386 and PowerPC. It is enabled by default.

To disable the JIT, set the "PLTNOMZJIT" environment variable (to
anything) or supply the --not-jit or -j command-line flag to
MzScheme/MrEd. At run-time, enable or disable the JIT through the
`eval-jit-enabled' parameter.

Of course, if you encounter any trouble that appears to be
JIT-inflicted, please let me know right away. I've tested the JIT quite
a bit, but there are a lot of opportunities for mistakes.


Performance:

For now, typical speedups from JIT compilation are in the range 1x
(i.e., no speedup) to 1.3x, with an occasional 2x or 4x. The JIT rarely
slows any program --- though, of course, it's possible. 

I expect to work on the JIT more, but probably not much, and I don't
know when or whether the perform of JITted code will improve. The
current JIT strategy is a simple translation of bytecode to native code
using GNU Lightning. Others are working on a more ambitious native-code
compiler, and I hope that it replaces my stop-gap effort.


Overhead:

JIT-compiled code tends to be 1.5x-3x the size of bytecode, but
"just-in-time" means "when a closure using the code is applied", so the
overhead should be small (because a program with lots of code usually
doesn't use much of it). JIT compilation usually requires very little
time. For example, on i386, JITting MrEd's code on startup grows the
initial footprint by 10%, and the JIT compile time is in the noise.


Debugging:

Depending on how MzScheme itself is compiled, JITed code may or may not
work with MzScheme's recently added stack-trace support. When it works,
the stack trace includes only JITted functions or only bytecode
functions (not both). Also, tail calls to primitives obscure the
calling procedure, unlike bytecode traces.

The stack trace for JITed code doesn't always work because it traverses
the C stack. In particular, it doesn't work for our Windows build,
because MzScheme is compiled with MSVC's frame-pointer omission.

There are many possibilities for improving the stack-trace support. For
example, JIT output could push stack-trace information onto a mark
stack like the bytecode (at some performance cost), or MzScheme could
take advantage of debugging information produced by the C compiler (to
traverse the stack without frame pointers). I'm not yet sure of the
relative benefits of JITting and stack traces, so I've put this on
hold.


3m:

If the JIT proves useful enough, I'll make it work for MzScheme3m.
Currently, the JIT is disabled for 3m.


Matthew