It's cool to get a look at a piece of assembly code that seems oddly familiar from all those times when my app has crashed in objc_msgSend due to a prematurely released object... (I still write non-ARC code for compatibility reasons. Sigh.)

I find the following claim slightly misleading:

32-bit x86 was quickly overtaken by 64-bit, so this code received little attention after Tiger and many of those inefficiencies remain to this day.

There are still major 3rd party apps that run in 32-bit mode on the Mac. Google Chrome is probably the most popular.

Does anyone know if this function is actually written in asm? Case in point:

    The code was probably originally written for NeXT
    by an engineer who was familiar with load-store
    architectures like PowerPC but not so familiar with
    register-memory architectures like x86 ... Those of
    you who do know x86 better may be able to identify
    some of the inefficiencies in this code

Fascinating stuff. It's so weird to realize that such a critical piece of code is still changing significantly after 10 years at NeXT and 10 years at Apple.

Related: If you want to see what messages are being passed around in your programs, you can use this: https://github.com/nviennot/objc-tracer

Where does he get that code from? The actual objc_msgSend function is much much longer and employs a bunch of other tricks.

As you can clearly see from the code it's perfectly acceptable in Objective-C to send a message to nil. This is a powerful feature that prevents the program from crashing but it is confusing for beginners.

Would be great to see the changes made in the ARM variants too. I know there's no value in compiling libobjc for ARM, but at least for academic value.