New Block Closures

Anthony Hannan ajh18 at cornell.edu
Thu Jun 21 15:31:46 UTC 2001


At 01:35 PM 6/20/2001 -0400, David M. Siegel <dsiegel at acm.org> wrote:

>At 05:55 PM 6/16/2001 -0400, Anthony Hannan wrote:
>> I've been writing block closures for Squeak.  [...] creates a
BlockClosure
>> object with a pointer to its own compiledMethod, the receiver (if
accessed),
>> the return home context (if it returns out (^)), and indexed slots for
>> captured temps from the outer scope.  Temps are put into value holders
>> (in the home context and the closure) iff they are changed and used
later.
>> I added new bytecodes to the Interpreter for accessing closure vars,
>> value holders, and for nilling out temps on there last use so they can be
>> free even if the context is still running.  Also, I've changed the
>> Interpreter to use frames on a stack instead of instantiating/recycling
>> contexts.  This saves copying the receiver and arguments at each send and
>> should allow a simpler JITTER implementation.  pushActiveContext creates
a
>> simple context object that refers to a frame on a stack.  When a stack is
>> full, a new stack is created and the sender slot contains a context
object
>> (refering to the old stack) instead of a frame pointer.

> I'd like to know a little more about the benefits of switching to frames
on
> a stack. I know that some language implementations have actually gotten
> better performance out of heap allocated structures (Appel's ML
> implementation's known for this).

My stacks are regular heap allocated objects that chain together when they
get full.  A stack holds context information for many contexts in a row.
The main benefit I see is that it eliminates the need to copy the receiver
and arguments on every message send.  It only needs to do this copy when
creating a new stack when the current stack is full.

- Anthony





More information about the Squeak-dev mailing list