As I see it, we have several separate things we want to achieve.
1. BC semantics.
2. Clean CMs
3. A little Performance (from stack and other small changes)
4. A lot of Performance (a new Jitter or some such)

It seems we can get both 1 & 2 without almost any new work. Because they
clean stuff up and simplify life on the image side, I think they're
worthy even without giving us speed. Heck, I'd take a 5% overall hit
without blinking, if it gets me rid of the Magical Compiled Methods.
Andreas seems to have suggested it is "slow" (not clear whether he meant
significantly slower than now, or just not faster). Does anyone have
benchmarks of the ClosureCompiler work with patched VMs?

About 3, the stack format+bytecode changes for a little speed but that
would make life harder later and whose author is no longer enthusiastic
about - doesn't sound like a very good deal.

About 4, we'll all be happy when we get it, but it seems to not be on
the table right now. Since it seems likely to not require image format
change (last Jitter didn't, IIRC), it doesn't affect the decision.

Daniel

Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> "Andreas Raab" <andreas.raab at gmx.de> wrote:
> 
> > Hi Anthony,
> > 
> > > 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. My inclination has been
> > that the ability to use the closure compiler is a bridge towards VI4 not a
> > permanent solution.
> That's certainly how I'd see it. The fact that it works reasonably well
> is great but there is definitely more that could be done by adding a few
> more bytecodes and/or primitives  and/or more block optimizing etc.
> 
> The major format change intended for VI4 is the compiled method clean up
> from several years ago. Having a format break provides us with an
> opportunity to clean up some other uglinesses as well and according to
> some old discussions with IanP would help with making a cleaner jitter
> someday. It also appears to improve performance a few percent on it's
> own. Some of the VM cleanups will reduce the VM size (as mentioned in
> another thread) and slighlty reduce the maintenance costs of the VM.
> 
> The _down_ side is the loss of backwards compatability with all those
> old images - but then they will still run on older VMs so maybe that
> is not such a big problem. Really the only thing in the way is finally
> making a decision to go forwards. Guides? Dan? Ted? Alan? Andreas?
> Anyone?
> 
> tim
> 
> -- 
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Useful random insult:- An 8080 in a StrongARM environment.