Hacker News Reader

Comment by adolph | Hacker News Reader

A GC system with explicitly visible reference counts (and immediate freeing) with language support to make it easier to get the refcounts right (things like automatically incrementing the refcounts when passing the object off to others) wouldn't necessarily be painful to use, and would clearly offer all the advantages of just doing it all by hand.

I was wondering how that was different from Cocoa on Objective-C.

See: http://developer.apple.com/library/mac/#documentation/Cocoa/...

View on HN

The runtime system might not free the memory immediately.

Could you expand on this thought? I assumed that free() was invoked in the dealloc method, which was explicitly called if the release method reached a zero ref count.

That's correct, unless the object is autoreleased, in which case the system will get around to deallocating it after the current run loop iterates (provided you're using the default autorelease pool).

Worth noting that an autoreleased object which you haven't retained will have a ref count of 1, so they are not an exception to the "freed when the ref count is zero" idea.

Yes, but if the object fall into the default autorelease pool you have no way to control when the memory is going to be released (at least without risking a segfault).

Thank you, that makes sense. So, if I understand this correctly: if one wanted to take advantage of an opportunity to do some cache-friendly reallocation, then avoiding autorelease pools would be necessary.

That's rarely a realistic option if you use any Cocoa library code. autorelease is a pretty fundamental aspect of the Cocoa design.

Wouldn't it be more accurate to say that it's not a realistic option for objects that come from or depend on Cocoa library code?

Or would the mere act of using cocoa in one part of my application somehow prevent me from exploiting such an opportunity in another part of my application?

My instinct says that, for example, a plain C library that used such techniques would not cease to function just by being linked into a cocoa application.

Yes, you're right: If you create objects yourself and don't pass them through certain Cocoa library code, they will not be autoreleased.

What I meant, however, is that most nontrivial Cocoa apps are likely to end up with a checkerboard allocation pattern, where the client allocated, controlled-lifetime objects are interspersed with Cocoa library allocated autoreleased objects with somewhat longer lifetimes, which may interfere to some extent with any strategy relying on controlling your object lifetime.

Still, people can and do avoid autoreleasing objects if their lifetimes are well known in advance.

Your instinct is correct.

Reply on news.ycombinator.com