Objective C message dispatch mechanism [closed]

Question

I am just staring to play around with Objective C (writing toy iPhone apps) and I am curious about the underlying mechanism used to dispatch messages. I have a good understanding of how virtual functions in C++ are generally implemented and what the costs are relative to a static or non-virtual method call, but I don't have any background with Obj-C to know how messages are sent. Browsing around I found this loose benchmark and it mentions IMP cached messages being faster than virtual function calls, which are in turn faster than a standard message send.

I am not trying to optimize anything, just get deeper understanding of how exactly the messages get dispatched.

• How are Obj-C messages dispatched?
• How do Instance Method Pointers get cached and can you (in general) tell by reading the code if a message will get cached?
• Are class methods essentially the same as a C function (or static class method in C++), or is there something more to them?

I know some of these questions may be 'implementation dependent' but there is only one implementation that really counts.

Wrung

Answer 1

How are Obj-C messages dispatched?

Objective-C messages are dispatched using the runtime's objc_msgSend() function. Shown in the Apple docs, the function takes at least 2 arguments:

1. The receiving object
2. The selector of the message
3. [A variable list of arguments to the message being sent.]

Instances of a class have an isa pointer, which is a pointer to their class object. The selectors of methods in each object are stored in a "table" in the class object, and the objc_msgSend() function follows the isa pointer to the class object, to the find this table, and checks whether the method is in the table for the class. If it cannot find it, it looks for the method in the table of the class's superclass. If not found, it continues up the object tree, until it either finds the method or gets to the root object (NSObject). At this point, an exception is thrown.

How do Instance Method Pointers get cached and can you (in general) tell by reading the code if a message will get cached?

From Apple's Objective-C runtime guide on Messaging:

To speed the messaging process, the runtime system caches the selectors and addresses of methods as they are used. There’s a separate cache for each class, and it can contain selectors for inherited methods as well as for methods defined in the class. Before searching the dispatch tables, the messaging routine first checks the cache of the receiving object’s class (on the theory that a method that was used once may likely be used again). If the method selector is in the cache, messaging is only slightly slower than a function call. Once a program has been running long enough to “warm up” its caches, almost all the messages it sends find a cached method. Caches grow dynamically to accommodate new messages as the program runs.

As stated, caching starts to occur once the program is running, and after the program has been running long enough, most of the method calls will run through the cached method. As it also says, the caching occurs as the methods are used, so a message is only cached when it is used.

Are class methods essentially the same as a C function (or static class method in C++), or is there something more to them?

Class objects handle method despatch in a similar manner to that of instances of classes. Each class object has an object that stores its own class methods, in an object called a metaclass. The class object has its own isa pointer to its metaclass object, which in turn has super metaclass objects, which it can inherit class objects from. Method dispatch to class methods is as so:

1. The dispatch system follows the class object's isa pointer to the metaclass object
2. The metaclass object's method table is searched for the class method.
3. If not found, the search continues to the metaclass object's superclass, where the search continues.
4. This process repeats until either the method is found, or until it gets to the root metaclass, and an exception is thrown.

Microampere

Excellent explanation. I find that understanding the dynamic dispatch system and how selectors are involved also explains rather well why method names must be unique, and Objective-C doesn't support overloaded methods in the same way Java and C++ do. Because the selector is cached as an integer, any method with the same name would map to the same selector. For better or for worse, it does force programmers to think more about properly naming methods. – Nowadays

If you want to go deep... friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map – Lassa

What about the special 'forward' and 'performv' methods? When are they called? – Handling

Answer 2

Dispatch mechanisms

It is used to find a necessary executable code when method was called(message sent)

• Inline
• Static(Direct)(C, Java final, C++ default, Swift static, final) - compiler knows the necessary method realisation at compile-time.
• Dynamic - is based on witness table(virtual table, dispatch table) and it introduce polymorphism
  • Table, V-Table(C++ virtual, Java default, Swift default) - Every object has a reference to class which has a table with all method addresses(super, overrides, new). SIL contains vtable or witness_table
  • Message(Objective-C, Swift dynamic) - Every object has a reference(isa) to class which contains a reference to superclass and dispatch table(which contains only realised methods(new and which were overhead)) and don't contain methods from super. If method was not found in current dispatch table, it continue searching in superclass's dispatch table. This process is optimised by caching. SIL contains volatile Objective-C Message Dispatch

For example

class A {
    func foo1() {}
    func foo2() {}
}

class B: A {
    override func foo2() {}
    func foo3() {}
}

Objective-C obc_msgSend

id obc_msgSend(id self, SEL op, ...)
// self - object which receive a message
// op - selector of method
//... - arguments

If method implementation was not found for given selector you see next error

unrecognized selector sent to instance

Upgrowth