[Newcompiler] Finding enough bytecodes for closures.

[bryce at kampjes.demon.co.uk]

Klaus D. Witzel writes:
 > Hi Bryce,
 > 
 > as part of your investigation, did you observe any chance to reduce the  
 > burden of having an instance of BlockClosure *and* of ClosureEnvironment,  
 > that'd be interesting.

First the new compiler only creates a BlockClosure and an
ClosureEnvironment if the block captures variables from it's
surrounding scope.

   self ifAbsent: [Set new].

Builds the BlockClosure at compile time. In this case, especially if
the block closure isn't called the closure code will be much faster.

Even in the worst case where both a ClosureEnvironment and a
BlockClosure is created the closure compiler may be much faster than
the BlockContext compiler. The BlockContext must be allocated, and the
the current context and all it's senders can not be recycled. In every
case the BlockContext code needs to create at least 2 objects and
possibly a lot more to replace the no longer recyclable contexts.

The BlockContext is used as the executing context but closure code
should be able to use MethodContext recycling more effectively. The
closure code will normally only need to pull a context off a list then
copy the arguments into it. Sends take about 200 cycles, the
difference between getting an item off a list and just using the
BlockContext is not that significant.

Yes it is possible to eliminate many ClosureEnvironments, they're only
needed when variables are actually captured from that scope. Removing
the closures is just creating extra kinds of block similar to the
different kinds of context that Eliot added in VisualWorks
5i. Creating extra context types is probably not needed to equal or better
the current code in most cases.

Bryce