Welcome back to another Friday Q&A. This week I'd like to take Joshua Pennington's idea and elaborate on a particular facet last week's topic of the Objective-C runtime, namely messaging. How does messaging work, and what exactly does it do? Read on!
Definitions
Before we get started on the mechanisms, we need to define our terms. A lot of people are kind of unclear on exactly what a "method" is versus a "message", for example, but this is critically important for understanding how the messaging system works at the low level.
- (int)meaning { return 42; }0x12345678.SEL. Selectors are essentially just opaque strings that are managed so that simple pointer equality can be used to compare them, to allow for extra speed. (The implementation may be different, but that's essentially how they look on the outside.) Example:@selector(meaning).Methods
The next thing that we need to discuss is what exactly a method is at the machine level. From the definition, it's a piece of code given a name and associated with a particular class, but what does it actually end up creating in your application binary?
Methods end up being generated as straight C functions, with a couple of extra parameters. You probably know thatself is passed as an implicit parameter, which ends up being an explicit parameter. The lesser-known implicit parameter_cmd (which holds the selector of the message being sent) is a second such implicit parameter. Writing a method like this:
-(int)foo:(NSString*)str{...
intSomeClass_method_foo_(SomeClass*self,SEL_cmd,NSString*str){...
What, then, happens when we write some code like this?
intresult=[objfoo:@"hello"];
intresult=((int(*)(id,SEL,NSString*))objc_msgSend)(obj,@selector(foo:),@"hello");
What that ridiculous piece of code after the equals sign does is take theobjc_msgSend function, defined as part of the Objective-C runtime, and cast it to a different type. Specifically, it casts it from a function that returnsid and takesid,SEL, and variable arguments after that to a function that matches the prototype of the method being invoked.
To put it another way, the compiler generates code that callsobjc_msgSend but with parameter and return value conventions matched to the method in question.
Messaging
A message send in code turns into a call toobjc_msgSend, so what does that do? The high-level answer should be fairly apparent. Since that's the only function call present, it must look up the appropriate method implementation and then call it. Calling is easy: it just needs to jump to the appropriate address. But how does it look it up?
The Objective-C headerruntime.h includes this as part of the (now opaque, legacy)objc_class structure members:
structobjc_method_list**methodListsOBJC2_UNAVAILABLE;
structobjc_method_list{structobjc_method_list*obsoleteOBJC2_UNAVAILABLE;intmethod_countOBJC2_UNAVAILABLE;#ifdef__LP64__intspaceOBJC2_UNAVAILABLE;#endif/* variable length structure */structobjc_methodmethod_list[1]OBJC2_UNAVAILABLE;}OBJC2_UNAVAILABLE;
objc_method structs. That one is in turn defined as:structobjc_method{SELmethod_nameOBJC2_UNAVAILABLE;char*method_typesOBJC2_UNAVAILABLE;IMPmethod_impOBJC2_UNAVAILABLE;}OBJC2_UNAVAILABLE;
So even though we're not supposed to touch these structs (don't worry, all the functionality for manipulating them is provided through functions in elsewhere in the header), we can still see what the runtime considers a method to be. It's a name (in the form of a selector), a string containing argument/return types (look up the@encode directive for more information about this one), and anIMP, which is just a function pointer:
typedefid(*IMP)(id,SEL,...);
objc_msgSend has to do is look up the class of the object you give it (available by just dereferencing it and obtaining theisa member that all objects contain), get the class's method list, and search through the method list until a method with the right selector is found. If nothing is there, search the superclass's list, and so on up the hierarchy. Once the right method is found, jump to the IMP of method in question.One more detail needs to be considered here. The above procedure would work but it would be extremely slow.objc_msgSend only takes about a dozen CPU cycles to execute on the x86 architecture, which makes it clear that it's not going through this lengthy procedure every single time you call it. The clue to this is anotherobjc_class member:
structobjc_cache*cacheOBJC2_UNAVAILABLE;
structobjc_cache{unsignedintmask/* total = mask + 1 */OBJC2_UNAVAILABLE;unsignedintoccupiedOBJC2_UNAVAILABLE;Methodbuckets[1]OBJC2_UNAVAILABLE;}
Method structs, using the selector as the key. The wayobjc_msgSendreally works is by first hashing the selector and looking it up in the class's method cache. If it's found, which it nearly always will be, it can jump straight to the method implementation with no further fuss. Only if it's not found does it have to do the more laborious lookup, at the end of which it inserts an entry into the cache so that future lookups can be fast.(There is actually onemore detail beyond this which ends up being extremely important: what happens whenno method can be found for a given selector. But that one is so important that it deserves its own post, so look for it next week.)
Conclusion
That wraps up this week's edition. Come back next week for more. Have a question? Think Objective-C's messaging system should be done differently? Post below.
Remember, Friday Q&A is powered by your ideas. If you have an idea for a topic, tell me! Post your idea in the comments, ore-mail them directly to me (I'll use your name unless you ask me not to).
Add your thoughts, post a comment:
Spam and off-topic posts will be deleted without notice. Culprits may be publicly humiliated at my sole discretion.