I ran macrobenchmarks (after fixing it up, see my fixes posted).  The
results are:

3.4 image with closure compiler loaded and active but no methods
recompiled:
	#(67308 246197 116342 31254 0 16290 14740)
3.4 image with closure compiler active and all method recompiled under
closure compiler:
	#(85788 348667 124072 46906 0 18674 23292)

Since marcroBenchmarks mostly tests the compiler/decompiler and
messageTally (hence contexts), most of these test are not executing
exactly the same code from the first image to the second.  The only test
that doesn't change is number 6, the one that opens and closes 10
browsers.  Number 6 results are 18674 vs. 16290, a 15% slow down.

Let me clarify why I think we should wait for a Jitter before changing
the image format.  Because the Jitter itself will likely required a
image format change and we don't want two format changes in a row,
especially when the second will superscede the first.  Only the compiled
method format change would remain from the first change, which could
wait for the second because it is only an aesthetic change.  It adds no
new functionality.

I know past Jitters did not require a format change.  But since Ian is
on Eliot's Bytecode-to-Bytecode Adaptive Optimization for Smalltalk
project (along with myself, Dan, Marcus, and John Sarkela) I suspect the
next Jitter will be a Smalltalk Jitter producing optimized bytecodes. 
Some of these bytecodes will be new special low-level bytecodes, which
will require a new image format.  Even if Ian produces a C Jitter before
that with no format change, it will speed things up enough to not need
VI4.  Only the compiled method format change will be missing, which
again is not important.

So I believe we can live with the 15% slow down for a year or so.  If
not we can try to speed up the interpreter a little by just including
stack enhancements but not bytecodes enhancements so we don't change the
image format.  I think any bytecode changes should be in conjunction
with Eliot's project or some Jitter project.  And to reiterate, I think
the compiled method format change should only be include on the back of
some other more significant image format change like bytecodes.

Cheers,
Anthony