[Vm-dev] normalSend, specialObjectsArray and VM
Mariano Martinez Peck
marianopeck at gmail.com
Sat May 8 22:08:35 UTC 2010
On Fri, May 7, 2010 at 11:10 PM, Igor Stasenko <siguctua at gmail.com> wrote:
> On 7 May 2010 23:04, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > On Fri, May 7, 2010 at 2:30 AM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
> >> Hi folks. I need to intercept ALL message sends. For the moment, I
> intercepted in Interpreter >> normalSend
> >> But now, I have a question: I know there is that specialObjectArray that
> contain objects that may be accessed by the VM.
> >> So, the first question is, they are only ACCESSED and to things with
> pointers or they also send messages to those objects from the VM?
> > Only accessed. The Interpreter has specialObjectsArray as one of its
> object references (along with nil, true, false) and indexes it with indices
> stored in class variables such
> as SpecialSelectors, CharacterTable, ClassMessage et al. See implementors
> and senders of splObj:.
> >> If the VM really send messages to those object, how that is done ? The
> code goes also by normalSend ? Or they go from somewhere else that I am not
> > At the bottom the VM has to access objects directly to avoid infinite
> regress. So the only sends are in response to send bytecodes, the perform:
> primitives, and other edge cases (looking up run:with:in: in the
> invoke-object-as-method prim and looking up a callback entry point in the
> Alien FFI).
> there's also a limited set of selectors, for which VM does not a
> normal send, but skips the standard lookup procedure, like with #class
Thanks Igor. I could see #class does not the normal way. It was logic as it
already has the pointer there ;)
Now I wonder...to avoid those special cases, do you think it makes sense to
intercept in commonSend rather than commonSend ? or it would be the same ?
> >> Thank you very much.
> >> Mariano
> > chers
> > Eliot
> Best regards,
> Igor Stasenko AKA sig.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev