[ENH] ContextCleanup-ajh ( [cd][er][et][su] extremely useful; unclear about ContextTag )

Anthony Hannan ajhannan at yahoo.com
Fri Jun 27 14:43:19 UTC 2003


Avi Bryant <avi at beta4.com> wrote:
> 
> On Thu, 26 Jun 2003, Anthony Hannan wrote:
> 
> > But I would still like to have working stack copies in conjunction with
> > possible other experiments like delegation.  What if we used receiverMap
> > to hold a record containing the ContextTag and other slots as desired
> > for delegation, JIT, etc.  Then we can have all at once instead of
> > choosing.  The record would only be created on demand (contextTags are
> > only needed for signal contexts and block closure homes).  And the extra
> > indirection is still pretty cheap.  What do you think?
> 
> What was wrong with Andreas' suggestion that ContextTag be a package that
> could be loaded by those that need correct stack copying, but not part of
> the base enhancements?

Then you could never load more than one enhancement that uses the receiverMap
at the same time.  Adding a ContextExtension record allows us to load as many
as we want (or for a single enhancement to utilize more than one slot).

>  Since AFAIK the only current user of Continuation
> is Seaside, and it can make do without ContextTag, it seems unfortunate to
> restrict ourselves or take a performance hit (and isn't BlockContext>>home
> used quite frequently?) for a total of 0 users.

I don't think there is a performance hit.  Returning to a block home also
involves checking for ensure:/ifCurtailed: contexts in between so I don't think
the extra indirection will be significant in comparison.  Also returning blocks
are actually quite infrequent.

> I very much appreciate the desire to make as much as possible work
> correctly out of the box, but - you've done the work on ContextTag and we
> know it's there if we need it, now let's find a reason to need it.  Until
> then, it doesn't make sense to me to give up the receiverMap slot or
> introduce any extra indirections.

All right, I just thought of another idea.  Since only particular contexts
(block homes, signal contexts, and #on:do: contexts) are referenced by a
contextTag, I can compile these specially so the contextTag is held in the
first temp instead of the receiverMap.  To make sure it is not some other
context that happened to store a random contextTag in its first slot, the
method will have to be marked as well.  But since we are out of header bits,
the code itself will be the marker.  Only contexts with contextTags will start
with the following code: pushThisContext, send: #contextTag, storePop: 0.

Cheers,
Anthony


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com



More information about the Squeak-dev mailing list