[Newcompiler] Finding enough bytecodes for closures.

[Klaus D. Witzel]

On Mon, 30 Apr 2007 22:47:05 +0200, Bryce wrote:
> 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.

Sure. But who wants BlockClosures without having "free" variables, this  
would be a contradiction and not worth the effort building a new compiler  
for them :|

> 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.

It cannot (be created faster than BlockContext): if an instance of  
ClosureEnvironment would be created *without* referencing it, it would be  
just garbage that is created.

Therefore, there are bytecodes needed to store (link) the instance (this  
is currently implemented by a message send plus storing the 5'th slot in  
thisContext). This amount of overhead cannot be amortized :(

In comparision to BlockContext: there's no such overhead.

Mathieu: you blogged "make the closures as fast as blocks were before",  
how would you eliminate such overhead?

> The BlockContext must be allocated, and the
> the current context and all it's senders can not be recycled.

Right.

> In every
> case the BlockContext code needs to create at least 2 objects

Two? What would be the other one?

> and
> possibly a lot more to replace the no longer recyclable contexts.

In terms of memory allocations (versus: recycling them from a list): sure.

> The BlockContext is used as the executing context but closure code
> should be able to use MethodContext recycling more effectively.

Right. But it currently does not so, since the closure code does  
#pushActiveContextBytecode :(

> 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.

Right.

> Yes it is possible to eliminate many ClosureEnvironments, they're only
> needed when variables are actually captured from that scope.

Sure "only if needed" but otherwise nobody would need a new compiler which  
handles full BlockClosures.

> 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.

Yes (extra context types probably not needed to equal or better), me too  
thinks that's not really needed.

Cheers
Klaus

> Bryce