|
|
|
|
|
|
by tdg
4392 days ago
|
|
|
I don't get how your code works. Why do you decrement first, then increment? Regardless, your explanation is mostly correct. There will be an incref/decref pair for most accesses. However, LLVM (and Apple's refcount implementation) does 2 very important optimizations: - LLVM can recognize (via static code analysis) redundant incref/decref pairs and take them out. - I can't find the link for it right now, but Objective-C usually stores refcount inside the pointer (in other words, the memory address) itself. So as long as your refcount is small enough (which it will be 99% of the time), incref and decrefs don't thrash caches but work on the value already in register. |
|
|
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.