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

Andreas Raab andreas.raab at gmx.de
Thu Jun 26 18:40:51 UTC 2003


Hi Avi,

Thanks this explains what ContextTag is designed for (your message really
ought to be part of its class comment). Thinking about it ... hm ... your
message does not entirely convince me that the use of ContextTag outside
cross-process continuation provides much additional value. E.g., if I
understand you correctly here (and please correct me if I'm wrong) then the
primary advantage of context tag is that you can copy a call stack and are
still able to "relatively refer" to frames on the stack without doing
additional work (such as fixing homes).

I've been looking at the EH related changes and it _seems_ to me that they
don't require context tags outside the above discussed scenario either. I
actually went as far as to change the references from tags back to contexts
and at all the tests were green, so it doesn't seem as if there are any
problems of using exceptions with either contexts or tags.

Because of the above (e.g., regular EH being able to deal with contexts
instead of tags) I feel *VERY* hesitant of giving up the *ONLY* slot in
contexts which can be used for experiments (with or without changing the
VM). Various people have in fact played with receiverMap (including it's use
for JIT, Stephen Pair's delegation VM etc) so fixing it now "for all times"
to refer to a context tag would effectively prevent anyone from doing these
kinds of experiments.

My proposal (unless other really good arguments come up) is the following:
Make ContextTag fully polymorphic with MethodContext (the only required
change is add #restartWithNewReceiver: to method context) and then - by
default - have MethodContext>>contextTag return self instead of an instance
of ContextTag.

If I understand the changes correctly, then its only implication is the one
we're living with today (e.g., being unable to copy call stacks "correctly"
without additional work).

Then, provide a package for ContextTag which - if installed - simply changes
the implementation of MethodContext>>contextTag to return an instance of
ContextTag (which may or may not be stored in the receiverMap). This would
allow applications which require cross-process continuations to use this
particular slot while not assuming that there is a de-facto use for
receiverMap throughout Squeak. E.g., if at some point, we want to use
receiverMap for something differently, all that happens is that this
particular package may break or needs to be changed to use a less efficient
implementation. From the POV of the long-term perspective both seem
preferable to me.

I feel very strongly about giving up receiverMap here. From looking at the
implementation I conclude that it may be unfeasable (as in: very
inefficient) to use a registry here (it feels like EH might be heavily
affected by this) and I do not feel that the additional value provided by
ContextTag really outweighs the limits that we put on Squeak for future
experimentation by giving up the only free slot in this area.

Cheers,
  - Andreas


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Avi Bryant
> Sent: Thursday, June 26, 2003 7:44 PM
> To: The general-purpose Squeak developers list
> Subject: Re: [ENH] ContextCleanup-ajh ( [cd][er][et][su] 
> extremely useful; unclear about ContextTag )
> 
> 
> 
> On Thu, 26 Jun 2003, Andreas Raab wrote:
> 
> > About the only change that isn't completely obvious to me is the
> > introduction of ContextTag for identifying references to 
> contexts. Using
> > a context's receiverMap instance variable 'because it's 
> unused' looks
> > like a hack (why not use a registry? if they are only needed for
> > continuations it seems that the speed implications of storing it
> > internally vs. in a registry should be irrelevant) and it is unclear
> > where exactly the advantage of using ContextTag is. While 
> test cases are
> > provided they do not illustrate any of the advantages of 
> using context
> > tags.
> 
> I can't speak to the use of receiverMap.  However, I can try 
> to explain
> the advantages of ContextTag.  Occasionally, an object 
> somewhere in the
> stack will be pointing a a context earlier in the stack - for 
> example, the
> "home" of a BlockContext:
> 
> MethodContextA <------
>    |                 |
> MethodContextB    (home)
>    |                 |
> BlockContextC  -------
> 
> A simple minded implementation of Continuation will do a shallow copy
> of the entire stack, recursively replacing each sender in 
> turn.  In the
> above case, the BlockContext ends up pointing to the wrong home:
> 
> MethodContextA <--           MethodContextA'
>    |             |               |
> MethodContextB   |           MethodContextB'
>    |             |               |
> BlockContextC    ---(home)-- BlockContextC'
> 
> Similar situations occur if you try to copy the stack during exception
> handling.
> 
> In Seaside, my first solution was that whenever I copied a stack, I
> manually walked it looking for BlockContexts and fixing up the home
> pointers.  This mostly worked, although there were still times during
> exception handling where capturing a continuation will break. 
>  These were
> obscure enough that I never bothered writing code to fix them.
> 
> Very recent versions of Seaside take advantage of the fact that
> Continuations are tied to Processes - I'm always executing a 
> Continuation
> in the same Process, which means I'm never executing two copies of the
> same stack at the exact same time.  Thus, instead of ever 
> actually using a
> copied stack, invoking a continuation reuses the original 
> context objects,
> restoring their pc/sender/etc values as needed.  Because the 
> identity of
> the contexts never changes, "home" references and so on don't need any
> special treatment.
> 
> The idea of a ContextTag is that rather than ever holding 
> directly onto
> context objects that are above you in the stack, you hold onto a "tag"
> object that is unique for that context in that copy of the 
> stack - to find
> the actual context, you walk the senders until you find one 
> with the right
> tag.
> 
> This means that when you copy the stack, as long as you 
> adjust the sender
> references, everything else will follow.  It's a nice, 
> general, elegant
> solution.
> 
> Personally, however, I would be happy enough not to have 
> ContextTag, and
> to simply impose the restriction (as current versions of 
> Seaside do) that
> you can't have multiple concurrent invocations of the same 
> Continuation.
> This is not that uncommon a restriction - I know that Ruby 
> and PLT Scheme
> both have it as well.
> 
> Hope this clarified things somewhat.
> 
> Avi
> 
> 
> 



More information about the Squeak-dev mailing list