Implementing Runtime Object Messaging

Implementing Runtime Object Messaging

The runtime library includes functions that provide access to the following information (the functions are identified in parentheses):

• The class definition of an object (objc_getClass)
• The superclass for a class (class_getSuperclass)
• The metaclass definition of an object (objc_getMetaClass)
• The name of a class (class_getName)
• The version information for a class (class_getVersion)
• The size of a class in bytes (class_getInstanceSize)
• The list of instance variables for a class (class_copyIvarList)
• The list of methods for a class (class_copyMethodList)
• The list of protocols for a class (class_copyProtocolList)
• The list of properties for a class (class_copyProperyList)

Taken together, the runtime data types and functions give the runtime library the information it requires to implement various Objective-C features, such as object messaging (see Figure 8-4).

Figure 8-4. Runtime system messaging operation

When you send a message to an object, the runtime looks up the instance methods for the class via custom code that leverages the class method cache and its vtable. It searches the entire class hierarchy for the corresponding method, and when found, jumps to the method implementation. The runtime library includes numerous design mechanisms to implement object messaging. You’ll look at a few of these, beginning with vtables.

Method Lookup via vtables

The runtime library defines a method data type (objc_method), as shown in Listing 8-7.

Listing 8-7.  Runtime Library Method Data Type

struct objc_method
{
  SEL method_name;
  char * method_types;
  IMP method_imp;
};
typedef objc_method Method;

method_name is a variable of type SEL that describes the method name; method_types describe the data types of the parameters of the method; and method_imp is a variable of type IMP that provides the address of the function invoked when the method is selected for invocation (recall that Objective-C methods are, in fact, C functions that take at least two arguments: self and _cmd). Because method invocation occurs potentially millions of times during the execution of a program, the runtime system requires a fast, efficient mechanism for method lookup and invocation. A vtable, also called adispatch table, is a mechanism commonly used in programming languages to support dynamic binding. The Objective-C runtime library implements a custom vtable dispatching mechanism designed to maximize both performance and flexibility. A vtable is an array of IMPs (Objective-C method implementations). Every runtime Class instance (objc_class) has a pointer to a vtable.

Each Class instance also includes a cache of pointers to recently used methods. This provides performance optimization for method calls. The logic implemented by the runtime library to perform method lookup is shown in Figure 8-5.

Figure 8-5. Runtime library method lookup

In Figure 8-5, the runtime library first searches the cache for the method IMP (pointer to the start of the method implementation). If not found, it then looks for the method IMP in its vtable, and if found, the IMP is then stored in the cache for future lookups. This design enables the runtime to perform a fast and an efficient method lookup.

Selector Uniquing via the dyld Shared Cache

The startup overhead for an Objective-C program is directly proportional to the amount of time required for selector uniquing. A selector name must be unique across an executable program, however, your custom classes and every shared library in your program contain their own copies of selector names, many of which may be duplicates (i.e., alloc, init, etc.). The runtime needs to choose a single canonical SEL pointer value for each selector name, and then update the metadata for every call site and method list to use the unique value. This process must be performed at application startup and uses up system resources (memory and program startup time). To make this process more efficient, the runtime performs selector uniquing through use of the dyld shared cache. 

dyld ( dyld - the dynamic link editor)is a system service that locates and loads dynamic libraries. It includes a shared cache that enables these libraries to be shared across processes. The dyld shared cache also includes a selector table, thereby enabling selectors for shared libraries and your custom classes to be accessed from the cache. Thus, the runtime is able to retrieve selectors for shared libraries from the dyld shared cache, and only needs to update selectors for your app’s custom classes.

Accessing Class Instance Methods

Now that you know how the runtime library looks up (and invokes) instance methods, you may be wondering how it does this for class methods (i.e., perform object messaging for class methods).Well, every Objective-C class is also, in fact, an object, hence it is capable of receiving messages, such as

[NSObject alloc]

So that explains how you can send messages to classes, but how does the runtime find and invoke class methods? Well, the runtime library implements this capability with metaclasses.

A metaclassis a special type of class object that stores information that enables the runtime to look up and invoke the class methods of an Objective-C class. There’s a unique metaclass for every Objective-C class because every class potentially has a unique list of class methods. The runtime API provides functions for accessing metaclasses.

Class hierarchies are observed with metaclasses, as with regular classes. In the same way that a class points to a superclass with its superclass pointer, a metaclass points to the metaclass of a class’s superclass using its own superclass pointer (refer back to Figure 8-4).

The base class’s metaclass sets its superclass to the base class itself. The result of this inheritance hierarchy is that all instances, classes, and metaclasses in the hierarchy inherit from the hierarchy’s base class.

The isa variable for an object points to a class that describes that instance, and can thus be used to access its instance methods, ivars, and so forth. The isa variable for an Objective-C class (object) points to a metaclass that describes the class (its class methods, etc.).

Putting this all together, the runtime performs messaging for both instance and class methods, as follows:

• When your source code sends a message to an object, the runtime retrieves the appropriate instance method implementation (via the corresponding class instance method vtable) and jumps to that method.
• When your source code sends a message to a class, the runtime retrieves the appropriate class method implementation (via its metaclass class method vtable) and jumps to that method.