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

Mariano Martinez Peck marianopeck at gmail.com
Fri Dec 23 10:59:01 UTC 2011


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.

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


More information about the Vm-dev mailing list