Squeak Object Engine Message Sending clarification

No need to go into details as I am just attempting to avoid a misconception.

On page 5 of 28 on Tim Rowledge's (very useful and enjoyable, btw) A Tour of the Squeak Object Engine
 I am unclear as to what  object's header' refers to in step I.


To send a message to a receiver, the VM has to:-
   I.        find the class of the receiver by examining the object's header. 
   II.       lookup the message in the list of messages understood by that class
       (the class's MethodDictionary)
........etc...


It seems 'obvious' to me that it has to be something in the current MethodContext,  and that 'object' does not refer to something out in ObjectMemory

Is that a valid assumption?

The BlueBook states this methodology

****** Messages PDF 584
       When a send bytecode is encounterd the interpreter finds the CompiledMethod indicated by the message as follows:
       1. /Find the message receiver./ The receiver is below the arguments on the stack. The number of arguments is indicated in the send bytecode.
       2. /Access a message dictionary./ The original message dictionary is found in the receiver's class.
       3. /Look up the message selector in the message dictionary./ The selector is indicated in the send bytecode.
       4. /If the selector is found,/ the associated CompiledMethod describes the response to the message.
       5. /If the selector is not found,/ a new message dictionary must be searched (i.e. go to step 3) but check the method dictionary of the superclass of the last class.

       6. /If all the superclasses are searched and the selector is not found, an error is reported and exectuion of the bytcodes following the send is suspended.


Meanwhile, the structure of the Squeak MethodContext  has a pointer to the receiver as well.

       + Method Context Structure
         + ---------------------------------------
         + ^ sender (pointer to previous context)
         + ---------------------------------------
         + instruction ponter   --------> points to current bytecode in the CompiledMethod's 'Bytecodes' section (see Format of CompiledMethod instances above)
         + ---------------------------------------
         + stack Pointer        --------> points to Stack Contents at bottom of this structure
         + ---------------------------------------
         + method               --------> points to MethodHeader section in the CompiledMethod (see Format of CompiledMethod instances above)
         + ---------------------------------------
         + unused
         + ---------------------------------------
         + receiver
         + ---------------------------------------
         + arguments
         + ---------------------------------------
         + temporaries
         + ---------------------------------------
         + stack contents
         + ---------------------------------------




Thx.

tty.

Thank you Tim.

From what I have gathered in this thread, the process is (loosely speaking, I will tighten up my terminology when I see the outline of the parts and delve into the details)...

0. VM references stack for Oop
1. Using the Oop, VM references the header on the object in ObjectMemory (see comment in ObjectMemory)
2.....

Just that fact that it goes out to ObjectMemory, instead of "receiver class methodDict" to me, hints at some interesting stuff and is a
very important distinction.


Thank you all again,

On 08-12-2013, at 8:19 AM, gettimothy <[hidden email]> wrote:

> No need to go into details as I am just attempting to avoid a misconception.
>
> On page 5 of 28 on Tim Rowledge's (very useful and enjoyable, btw) A Tour of the Squeak Object Engine
> I am unclear as to what object's header' refers to in step I.
>
>
> To send a message to a receiver, the VM has to:-
> I. find the class of the receiver by examining the object's header.
> II. lookup the message in the list of messages understood by that class
> (the class's MethodDictionary)
> ........etc…

Back on page 2 of my doc, -
> 1. Creating Objects
>
> Unlike structures in C or records in Pascal, Smalltalk objects are not simply chunks of memory to which we have pointers, and so we need something more sophisticated than the C library malloc() function in order to create new ones.
> Smalltalk creates objects by allocating a chunk of the object memory and then building a header that provides the VM with important information such as the class of the object, the size and some content format description.

I really ought to update the doc and add some more diagrams etc.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Recedite, plebes! Gero rem imperialem! = Stand aside plebians! I am on imperial business.