On Fri, Dec 23, 2011 at 2:59 AM, Mariano Martinez Peck <marianopeck@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@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