2009/7/17 Eliot Miranda <eliot.miranda at gmail.com>:
> 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 :)
>
Hmm.. since when 'MethodContext clone' is too expensive?

I was more expecting that you say that it can be expensive when
allocating new contexts (because it should pick the right 'class' for
it , as i described, instead of taking already known class from
special objects array). Or it could be problematic in places where VM
should make difference between contexts and other objects , since
contexts now could have any object as a class , not just a single,
fixed one.

And, of course, such overhead can be eliminated, by merging behavior
from Process to MethodContext class side.
So, instead of creating a Process instance - you creating an anonymous class :)
But this would require a bit of refactoring... :)



> 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.
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.