mikeash.com pyblog/friday-qa-2011-09-16-lets-build-reference-counting.html comments

gparker - 2011-09-28 19:10:37

Wed, 28 Sep 2011 19:10:37 GMT

A common bug is to call -dealloc a second time if the implementation of -dealloc retains and releases self. Your implementation does not have this bug. Exercise: why not?

mikeash - 2011-09-28 16:20:08

Wed, 28 Sep 2011 16:20:08 GMT

If I were building my own implementation for practical purposes, I would definitely use an inline reference count as you describe. However, my intent was to replicate what Apple does, and Apple uses a big global table.

The question then becomes, why does Apple use that? I can only speculate, but I think it probably made a great deal more sense back when this stuff was first built. Multithreaded performance was completely unimportant at the time, but memory was at a premium. An inline reference count means an additional four bytes in every object. A global table with "no entry" being interpreted as 1 could represent a significant savings if retain counts >= 2 are rare, as they probably are in many programs.

Dominic Hopton - 2011-09-27 17:51:44

Tue, 27 Sep 2011 17:51:44 GMT

n00b question:
Why would you not hold the count on the object? Wouldn't that allow you to use CPU optimizations such as atomic increment/decrement operations, rather than the giant lock you've got here, as well as not needing the table look ups. (isn't that single global lock a bottle neck across large [de]allocations?)

mikeash - 2011-09-17 16:42:53

Sat, 17 Sep 2011 16:42:53 GMT

It's an error to retain, or indeed manipulate an object in any way, from one thread while another thread is in the process of releasing the last retain on it. You have to do your own locking to synchronize things in that case, or better yet have both threads do their own retains.

ptx - 2011-09-17 16:03:30

Sat, 17 Sep 2011 16:03:30 GMT

The DecrementRefcount function unlocks the spinlock before the reference count is returned, couldn't this mean that if ma_retain is called from another thread just as me_release have read the reference count that the object is deallocated by mistake?

mikeash - 2011-09-17 00:30:41

Sat, 17 Sep 2011 00:30:41 GMT

That's an excellent point. You'd never want to build an implementation like this for real, unless of course you were reimplementing reference counting from scratch for some other environment. There have been performance advantages for redoing reference counting to use inline storage, but it sounds like that's now largely moot on 10.7, and in any case still breaks the weak reference stuff.

Chris Lattner - 2011-09-16 17:25:28

Fri, 16 Sep 2011 17:25:28 GMT

Thanks for the very educational article Mike!

I'd just like to point out a couple of very important things: first, this implementation is not compatible with "zeroing weak" pointers in ARC: they will explode at runtime or malfunction if you try to use them with classes like this. Second, this is not actually faster than NSObject's implementation, and defeats the runtime optimizations that happen in objc_retain and friends.

In other words, I think it's great that you peeled off the covers to show how this stuff conceptually works, but it would be a bad idea for someone to actually go implement their own retain/release in a real app.

-Chris