"Andreas Raab" <andreas.raab at gmx.de> wrote:
> > I think we should abandon the VI4 idea (image format changes) for now
> > and just stick with the Closure Compiler which works with the current
> > image. 
> 
> Not good for the long-term as it is pretty slow.

I didn't think it was noticeably slow for typical usage.  I will have to
do some macro benchark tests on a recompiled image.  Besides, for
critical code the closure compiler can be turned off.

I see Jitter or something like it for the long term, which would be faster
than VI4.  The only value VI4 has after Jitter comes along is CompiledMethod
format changes, which can wait.

> My inclination has been
> that the ability to use the closure compiler is a bridge towards VI4 not a
> permanent solution.

The closure compiler is the BC part of VI4 separate out, so it is the
end product for BC.  The remaining VI4 would add quicker bytecodes and
quicker stack execution, but Jitter would be even faster.

> > Image format changes can come later with the Jitter 
> > or possibly with my NoVM project (Squik).
> 
> Does this mean you are not planning to put any further work into the VI4/BC
> project?

Correct, unless we feel we can't wait for Jitter or something like it. 
I am very interested in Eliot Miranda's adaptive optimizing compiler
project which Ian is a part of.  I see this as the long term.

VI4 in its current state has all new bytecodes which may not be
appropriate for a Jitter, and the stack implementation needs to be
improved.  If we find that the closure compiler is inapproriately slow
and that Jitter/Eliot's project is too long term then I will implement a
new version of VI4 with an appropriate stack implementation and
re-address the bytecodes with an eye toward Jitter/Eliot compatibility.

But really I'm interested in more long term, my NoVM project.  The NoVM
project will include all the speed enhancements mentioned above, but
they would be implemented in Smalltalk (not Slang/C/C++).

Cheers,
Anthony