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