Re: Opinion on managed memory and garbage collection
Re: Opinion on managed memory and garbage collection
- Subject: Re: Opinion on managed memory and garbage collection
- From: Chris Idou <email@hidden>
- Date: Mon, 22 Jun 2009 23:39:44 -0700 (PDT)
I've written a reasonably non-trivial app using GC and using a fairly wide range of APIs. I've found several GC bugs in the Apple frameworks, which naturally enough are pretty annoying (as all memory problems are), but I don't think the annoyance is still anywhere near that of having to write memory release code, and then hunt down memory leaks.
I haven't noticed GC pauses. It seems to me that the GC collects memory extremely quickly, relative to when it becomes unreachable. Given that it apparently does a lot of work in another thread, I wouldn't expect there to be much pausing in "normal" applications.
________________________________
From: Michael Ash <email@hidden>
To: cocoa-dev <email@hidden>
Sent: Tuesday, 23 June, 2009 2:21:48 PM
Subject: Re: Opinion on managed memory and garbage collection
On Mon, Jun 22, 2009 at 10:58 AM, Phil Hystad<email@hidden> wrote:
> Being relatively new to Cocoa and Objective-C, what is the consensus on
> using the new version 2.0 managed memory features (garbage collection).
>
> If you were writing a new Cocoa application from scratch, would garbage
> collection be the preferred method over the reference counting
> (retain/release) method. Having spent years in Java I would prefer a GC'd
> approach but I have also seen the great improvement of GC in Java over the
> years. Therefore, I am also curious on how the new Objective-C design for
> GC compares.
>
> The applications I have in mind are mostly graphic (Quartz 2D) oriented and
> likely also some OpenGL work.
>
> Thanks for your opinions and comments.
IMO there are three major reasons to avoid GC at this point:
1) In 10.5 there are still significant bugs in the GC and, more
importantly, the GC support in the system frameworks. The GC bugs are
generally obscure and hard to hit, the frameworks are much easier to
hit and harder to work around. If you search the list archives you'll
probably turn up various posts where Apple people tell developers that
you can't use this API under GC, or it has some huge speed hit, or the
only way to avoid a crash is to deliberately leak an object, etc.
Hopefully 10.6 is better, but as always, the people who know can't say
and the people who can say don't know.
2) The GC pauses your threads at nondeterministic intervals and for an
unknown amount of time in order to scan its stack. If this pause is
significant enough, it could cause occasional visible stutter in your
graphics output. I have no idea what the chances are of this causing
problems for you, but it's something to watch out for.
3) By its very nature of trying to coexist in a C-based language, the
GC doesn't cover everything. This is by design. The GC covers ObjC
objects (including bridged CoreFoundation objects allocated in the
default zone) and raw memory that you explicitly allocate with the
collector. Anything that's allocated with raw malloc/free stays
outside the garbage collector. This is a big advantage in that any raw
C code that you happen to have (or load) will almost certainly Just
Work in a garbage collected environment, which I'm sure is a big part
of why the Apple GC guys chose to make it work this way. The downside
is that your interactions with the collector often become more manual
than you might like if you drop out of the Ideal Pure Objective-C
World and into the guts of C. The code you write here will offset your
savings from not having to write retain/release code, and worse, this
code is usually much more complex and error-prone.
I have not done a lot of serious work with GC, although I have a
half-completed project and some toy projects that use it. My personal
impression is that if you're doing a conventional, straightforward OS
X program which never colors outside the lines, you're likely to have
a good experience with it. If you're after high performance or are
doing anything "tricky" then you're likely to run afoul of it and
perhaps wish that you had gone the other way.
Retain/release has a long history, is very well understood, and
doesn't really require much mental (or typing) overhead once you know
it. With GC you're much more like a test pilot at this stage in the
game, especially since there are a lot of frameworks deficiencies
under GC which are known to Apple but which they haven't actually put
into the documentation. (List archives are your friend here.) GC has
more risk and potentially more reward. If you can aim for 10.6+, the
risk/reward ratio is probably going to be quite a bit lower, although
that's just speculation. Obviously the ultimate choice is yours.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Access Yahoo!7 Mail on your mobile. Anytime. Anywhere.
Show me how: http://au.mobile.yahoo.com/mail
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden