[squeak-dev] process-faithful debugging?

Eliot Miranda eliot.miranda at gmail.com
Fri Jul 17 04:20:29 UTC 2009


If I were going to modify the VM I'd simply add a bytecode to answer
thisProcess.  e.g. the thisContext bytecode would become a two-byte bytecode
(i is very rare in practice) and the second byte would indicate what special
pseudo-variable to answer.  What you propose below has the overhead of an
anonymous class per process (my closure scheme doesn't use BlockContext at
all any more).  Fun, but too expensive for my tastes :)

On Thu, Jul 16, 2009 at 6:44 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 2009/7/17 Eliot Miranda <eliot.miranda at gmail.com>:
> > Hi All,
> >     does anyone have a neat hack to make Processor activeProcess answer
> > what's expected in the context of the debugger?  i.e. anyone made the
> Squeak
> > debugger answer the process being debugger when Processor activeProcess
> is
> > stepped over or through, rather than the debugger process, or made the
> > debugger run as the process being debugged rather than its own?
>
> Very good question, Eliot!
> I always wondered, why to access the active process we use global -
> Processor.
> A running process is closely related to contexts, and therefore it
> would be more correct to ask a context about it's process rather than
> global:
>
> thisContext process
> instead of
> Processor activeProcess.
>
> I have an idea about this.
> Its hacky and will require VM modifications - but having much benefits IMO
> :)
> I think this is most clean & lean way to deal with process-local
> storage in smalltalk:
>
> - add 3 __class instance__ variables to ContextPart:
>  - methodContextClass
>  - blockContextClass
>  - process
>
> Now, when creating a new process , create a two anonymous subclasses
> of MethodContext and BlockContext,
> and fill these ivars in each one appropriately.
>
> Then, all contexts which allocated for given process should use these
> anonymous subclasses as their classes.
> For VM this means, that when it allocating new context, it should copy
> the class reference from caller context (or read a
>   methodContextClass or blockContextClass ivars in caller context
> class object).
>
> And then accessing a process ( or process-local storage) is trivial &
> quick:
>
> ContextPart>>process
>   ^ self class process
>
>
> > TIA
> > Eliot
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090716/3c2b66b3/attachment.htm


More information about the Squeak-dev mailing list