Hi Stephane,

Stephane Ducasse <ducasse at iam.unibe.ch> wrote:
> - Anthony mentioned that with his optimisations with full blockclosures 
> were getting 30% speed to squeak and ***true block closure***.
> - Allen Wirfs-brock mentioned that the techniques used were used all 
> over the places by other Smalltalk.
> - I had the impression that still what anthony was doing was a problem 
> for the VM guys (I may be wrong).
> I would like to understand if
> 	(1) what he did is good,
> 	(2) what are the problems to introduce them in Squeak (for example 
> with the optimizations is seaside continuation passing style still 
> working),
> 	(3) what would we lose,
> 	(4) what is the path to go with that?

I am backing off promoting VI4 as is.  I have realized there are still a
few areas that I would like to work further on before recommending it be
included in Squeak.  They are:

1. Bytecodes

The bytecodes I have in VI4 are a mix of high-level and low-level
operations, optimized for interpretation.  They are probably not the
most appropriate for JIT-compiling, which is the future.  Also, the
low-level operations are hard to verify as valid Smalltalk (for mobile
code).  A full decompile would be required, which is time consuming just
for verification.  Also, decompiling is very difficult; I still don't
have it totally working in VI4.  (Note: the decompiler for the standard
bytecodes in the latest Closure Compiler does work correctly).

For the next VI4 version, I would like to explore high-level bytecodes
that are made for JIT-compiling, kind of like Self's.

2. Execution Stack

Going from a linked list of contexts to a straight stack you lose the
tree structure of paths of control, which before I thought wasn't
needed, but now I believe paths of control are more naturally trees, not
stacks.  What I mean is a context could simultaneously trigger two or
more paths.  This is similar to forking a path except the context will
not resume until all triggered paths return.  This is not implemented in
current Squeak but I think we should leave this option open.  In light
of this, we can still optimize single sequences of contexts and put them
on a single stack, but these stacks should start new at fork points. 
Stack would be linked like contexts currently, creating a tree of
stacks.

Currently VI4 only has one stack per process.  I want to change this so
a process points to a tip of a stack-tree branch, like with contexts
currently.  Any reference to a context would start a new stack with the
referenced context in the first frame.  Contexts it calls that are not
externally referenced would exist in the same stack similar to how they
would be if they were inlined.

Cheers,
Anthony