[kannanvijayan]

My code doesn't work under race conditions. You're right the increment should be done before and the decrement after to avoid races. I just banged out the logic without giving it too much thought.

On removing redundant incref/decref pairs - this is nice, but it seems mostly a benefit because of the "automatic" part, not the refcounting part. Developers dealing with manual refcounting would probably recognize places where refcount manipulation is redundant and just elide them. A naive automation ends up inserting them everywhere, and this helps bring that back to what a "smart developer" would have written anyway.

On your second point, I've heard about this trick - in particular in smalltalk implementations. It's something I haven't fully looked into. It seems like the in-pointer refcount would only be valid if the pointer never escaped the function frame. More generally, you'd have to be able to guarantee that a particular pointer is the only reference to an object before the refcount could be stored in the pointer bits itself.

If you have more insight into the implementation of this, I'd be interested in hearing it. This "small refcount pointer tagging" thing is something I've been meaning to understand better but haven't gotten around to.

[tdg]

Hmm, turns out I am wrong about the second point. Obj-C does not store the refcount in the pointer address:

https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...

They store it in isa field. Still, as long as you also call any virtual method of the object (or due to cache lines, use any field), it will still be pretty fast.