[EMAIL PROTECTED] wrote:
They automatically build themselves
simple JIT backends (by extracting fragments produced by the ahead of
time compiler). This sounds like a great way to achieve portability
while achiving better performance than a conventional interpreter.
I guess it's a bit better or just comparable with a good interpreter.
They say it is a lot better: "speedups of up to 1.87 over the fastest
previous interpreter based technique, and performance comparable to
simple native code compilers. The effort required for retargeting our
implementation from the 386 to the PPC architecture was less than a
person day."
In 1998, I have written such a JIT compiler concatinate code fragments
generated by GCC for each JVM instruction.
Very interesting!
Unfortunately, the JIT was
slightly slower than an interpreter in Sun's Classic VM. The
interpreter was written in x86 assembly language and implements
dynamic stack caching with 2 registers and 3 states. It performs much
better than the previous interpreter written in C.
Then I rewrote the JIT.
It would be interesting to hear your perspective on Ertl & Gregg's
approach. Did they do something you had not done? Do they have any
particular insight? You are in an excellent position to make a critical
assessment of their work.
I am not very sure which is better for us, having a portable and so-so
baseline compiler or a good interpreter which is possibly less
portable than the compiler. There will be a trade off between memory
consumption, portability and so on.
Ideally we will have both as components and the capacity to choose
either or both depending on the build we are targetting.
Cheers,
--Steve
