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

Eliot Miranda eliot.miranda at gmail.com
Fri Dec 23 20:08:39 UTC 2011


On Fri, Dec 23, 2011 at 2:59 AM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
> Eliot, there is one place I have missing and I cannot intercept :(  which
> I think it makes sense.
> If there is a method which has been jitted (#foo: in the following
> example) and such method has message sends to another method which was
> jitted also (#name in the example), then I can never intercept the receiver
> of the second method. Test example:
>
> testTraceOnlyReceiverMethodInsideMethod
>
>     |  obj1 obj2 |
>
>     obj1 := 'anObject'.
>     obj2 := 'anotherObject'.
>     self deny: (tracer isMarked: obj1).
>     self deny: (tracer isMarked: obj2).
>
>     obj1 foo: obj2.
>     obj1 foo: obj2.
>     obj1 foo: obj2.
>     obj1 foo: obj2.
>
>     tracer trace:  [obj1 foo: obj2].
>
>     self assert: (tracer isMarked: obj1).
>     self assert: (tracer isMarked: obj2).
>
>
> So if I have
>
> foo: anObject
>     anObject name
>
>
> 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20111223/3880a595/attachment.htm


More information about the Vm-dev mailing list