objc_msgSend_vtable is a version
objc_msgSend used to optimize a few of the most
commonly called methods.
Most Objective-C methods are dispatched using a hash table lookup
objc_msgSend. On x86_64, a few selectors can be
dispatched using a C++-style virtual table: an array lookup, not a
The compiler knows which selectors are optimized by the runtime. It
compiles the call site differently,
objc_msgSend_fixup via a function pointer. At
objc_msgSend_fixup replaces the function
pointer with one of the
if the called selector is one of the optimized selectors.
C++ vtables are notoriously fragile: the array offsets for each
virtual method are hardcoded into the generated code. Objective-C's
vtables are not fragile. Each vtable is built at runtime and updated
when method lists change. In theory even the set of optimized
methods could be changed. The non-fragile flexibility costs an extra
memory load during dispatch.
Dispatch via vtable is faster than a hash table, but would consume
tremendous amounts of memory if used everywhere. Objective-C's
vtable implementation limits its use to a few selectors that are (1)
implemented everywhere, but (2) rarely overridden. That means most
classes share their superclass's vtable, which keeps memory costs
A crash in any
objc_msgSend_vtable function should be
debugged exactly like a crash in
itself. They both crash for all of the same reasons, like incorrect
memory management or memory smashers.
Currently, the runtime uses sixteen
objc_msgSend_vtable functions, one for each
slot in the sixteen-entry vtable.
The vtable's contents differ for GC and non-GC, for obvious
-isFlipped is part of
the fast enumeration implementation, including
for (x in
y). Together these methods make up roughly 30-50% of calls
in typical Objective-C applications.