[Vm-dev] Weird problem when adding a method to StackInterpreter

Mariano Martinez Peck marianopeck at gmail.com
Mon Dec 26 09:00:33 UTC 2011


>
>> Then the test fails in self assert: (tracer isMarked: obj2).  I imagine
>> it is because it is executing the machine code of #foo: . So my question is
>> if there is a way where I could intercept and trace the receiver also
>> there?   I tried to do it but I failed.
>>
>
> See the flag word traceLinkedSends in cogit.c.  A bit in the flags causes
> the JIT to generate a call at the start of a method for tracing:
>
> #define recordSendTrace() (traceLinkedSends & 2)
>
> The result is that ceTraceLinkedSend is called on every send.
>
>
Wow. I cannot believe how easy it was :)  Thanks Eliot. So what I did is to
change Cogit class >> declareCVarsIn:
to set 2 rather than 8:

        var: #traceLinkedSends
            declareC: 'int traceLinkedSends = 2';


And then just add my tracing stuff in #ceTraceLinkedSend

Thank you very much Eliot and Happy Christmas to all VM hackers



> HTH
> Eliot
>
>
>> Thanks a lot in advance,
>>
>>
>>
>> On Fri, Dec 23, 2011 at 11:23 AM, Mariano Martinez Peck <
>> marianopeck at gmail.com> wrote:
>>
>>>
>>>
>>>>> Weird ehh, because you use #internalStackValue:  along
>>>>> StackInterpreter in a lot of other places and you don't have problems
>>>>> there.
>>>>>
>>>>
>>>> Turns out it's not weird at all.  Since  lookupInMethodCacheSel:class:
>>>> is used outside of interpret in findNewMethodInClass: and in callback
>>>> lookup it can't be inlined and hence can't access localSP.
>>>>
>>>
>>>
>>> Hi Eliot. Thanks for you answer. It also turns out that I don't know
>>> enough about SLANG ;)  so it was not weird at all but expected. Ok, I am
>>> learning in the way. So I understand that sentence. But  (down)
>>>
>>>
>>>> If you want to get the receiver you'll need to use stackValue: *and*
>>>> you'll need to ensure that stackPointer is updated when
>>>> calling lookupInMethodCacheSel:class: from internalFindNewMethod (see
>>>> externalizeFPandSP), which may slow down the interpreter slightly.
>>>>
>>>>
>>> I DO understand what #externalizeFPandSP does, but what I don't
>>> understand is why I should only do it in #internalFindNewMethod. I mean,
>>> what happens with all the rest of the senders of
>>> #lookupInMethodCacheSel:class:   ?  maybe if one of those senders do not
>>> update stackPointer (externalizeFPandSP), then in
>>> #lookupInMethodCacheSel:class:  I will be accessing something wrong ?
>>>
>>> Anyway, I wanted to trace the receiver in
>>> #lookupInMethodCacheSel:class:  to avoid doing it in all its senders. But
>>> with the problem found, I workarrounded by tracing the receiver in its
>>> senders (only those inlined) and that seems to work :)
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>  You're going to have to delve into the inliner in Slang.  This is,
>>>>>> um, not fun.  I liken it to getting hit on the head with a stick by your
>>>>>> guru, except that no enlightenment results.  Good luck.
>>>>>>
>>>>>>
>>>>> :(   thanks.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mariano
>>>>>>> http://marianopeck.wordpress.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> best,
>>>>>> Eliot
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mariano
>>>>> http://marianopeck.wordpress.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> best,
>>>> Eliot
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>>
>
>
> --
> best,
> Eliot
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20111226/957072f9/attachment.htm


More information about the Vm-dev mailing list