[ENH] ContextCleanup-ajh ( [cd][er][et][su] extremely useful;
unclear about ContextTag )
Andreas Raab
andreas.raab at gmx.de
Fri Jun 27 17:05:38 UTC 2003
Hi Anthony,
I don't like the idea of "specially compiling things" at all here. It means
we change some fundamental assumptions about the way stuff gets compiled for
no really good reason.
About a context extension: This is certainly one way to deal with the issue
but for some reason I still feel hesitant. Since I'm not really sure what
exactly disturbs me here I'd like to get some feedback from other people in
this area.
Tim? John?
Cheers,
- Andreas
> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
> Behalf Of Anthony Hannan
> Sent: Friday, June 27, 2003 4:43 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: [ENH] ContextCleanup-ajh ( [cd][er][et][su]
> extremely useful; unclear about ContextTag )
>
>
> 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
|