Hacker News Reader

Comment by hamstergene | Hacker News Reader

You're mixing up Apple's ARC with reference counting in general.

A typical RC implementation suffers from either requiring to do AddRef/Release calls manually (what Apple had in pre-ARC era), or blindly doing too many automatic calls. That's ancient history and can not complete with a moderately decent modern GC.

ARC has neither of those disadvantages and so provides convincing alternative to GC, and AFAIK is the first and unique to do so.

BTW, the correct term to use here is "automatic memory management" (AMM), not garbage collection, and there is no such thing as "proper" AMM. Handling circular references is not a must-have property of AMM, it is just the price RC pays, in GC, that will be pauses and higher footprint, and other approaches exist too: for example, to disallow in compile time to create a structure that can be potentially circular.

View on HN

Something I've wondered about reference counting and optimising compilers: I assume at a lowish level an inlined function call might look something like,

    pointer->ref_count += 1
    obj = pointer->ptr
    //...do something with obj...
    pointer->ref_count -= 1
    if pointer->ref_count == 0:
        free(pointer->ptr)

Assuming ref_count isn't messed up by another thread (which I guess we're free to do if we haven't put locks around it, or declared it volatile?) then you could optimise away the increment and decrement on `ref_count`, right? I guess I wouldn't be surprised either way.

What I'd like to know, though, is whether the `ref_count == 0` check could get optimised away as well. To you and me it's obvious that the count is positive at the start (as a precondition for the pointer access being correct), but I can't really see how an optimising compiler could know that.

> ARC has neither of those disadvantages and so provides convincing alternative to GC, and AFAIK is the first and unique to do so.

I love what Apple has done with ARC: they've taken a very inefficient approach to garbage collection, one which has repeatedly shown to be the "worst case" algorithm with the worst performance characteristics, and then proceeded to convince legions of developers that that same approach is actually the best one.

Not only that, they managed to sell the idea they gave up on GC because their engineers didn't managed to make it work with C semantics that didn't crash left and right, but because ARC is way better than GC.

Nobody else ever put an optimizer in front of the refcounting calls to remove redundant pairs? I find that hard to believe.

ARC can add automatic calls when not needed (just to be safe). When converting from manual management to ARC for one of my projects I had to resolve performance issues found in tight loops where it inserted unneeded retain/releases.

Potentially dumb question, were you testing with optimizations enabled? ARC inserts calls everywhere, but then the optimizer does its best to take out redundant ones. It's not perfect, but it can make a big difference.

Good question actually... It was a few years ago; I know I was eyeing through my code using Instruments but I'm not sure if I profiled with optimizations on. I'll have to look back at my code to see if it'd make an impact with them on. Although having your debug build suffer significantly could be a valid concern.

So I took out all the "__unsafe_unretained"'s I inserted and indeed, with optimizations enabled in my release mode, the calls were removed. However, my no-optimization debug build is unbearably unusable like this so I cannot justify making this change.

Appreciate the report! Interesting outcome.

Reply on news.ycombinator.com