Garbage collection, work of the devil?

I wrote before about how I learned programming the Mac using a scripting language, using its native API call plug-in scheme and how that made me realize that using scripting languages and their bridges to other languages or the native APIs (or even AppKit) is a great way for people to learn programming at their own pace.

Today, someone on an Apple mailing list complained that Garbage collection was

replacing one problem with two problems, one of which is the precise shape of the original problem

because the unpredictability of when garbage is actually collected means you are still forced to manually manage scarce resources instead of letting the object's destructor take care of it.

That's a very one-sided view: The advantage of Garbage Collection is not that it solves the problem, but that it partially automates the common case. If you don't have to write a piece of code, you are less likely to forget writing it. And you are less likely to make silly mistakes (e.g. copying a release line, forgetting to adjust it, and then leaking one object and releasing the other twice).

In most of the cases, you don't care when a particular object is actually released, as long as you can reclaim the memory it uses up when you need it. The cases where an object actually equates to a resource other than memory are a fraction of the overall number of objects you use: The property list types alone get created and disposed of so often that a mistake in there can easily introduce subtle bugs much harder to track down than realizing your hold on a device or file or other scarce resource hasn't been relinquished.

People have programmed this way for ages. As above-linked article mentions, people would use AppleScript Studio because they are familiar with AppleScript, and can now, at their own pace, add new knowledge. They can add one small problem at a time, and learn to use AppKit and Foundation gradually, without having to familiarize themselves with the entire gargantuan complex system at once.

If you take one step back, you may as well ask the same question, once removed: Why do we use high-level languages that produce such inefficient code? Because most people don't want to debug their push/pop stack management code and make sure the alignment is right before each call if the language can take care of this for most of their uses. And for the few cases where they need it, they can use inline assembler.

Both are the same problem and the same solution, merely at another level. Language bridges, garbage collection and other conveniences are not here to completely save you from having to learn the details of the computer's workings. They are here so you can learn them later, out of order, and in smaller chunks. And they are also here to make life easier for those people that already know.

Reader Comments: (RSS Feed)

Jens Ayton writes: Wot, no context? :-) http://lists.apple.com/archives/objc-language/2009/Dec/msg00054.html

ssp writes: I couldn't agreee more on the benefits of garbage collection. Anything that makes standard tasks easier and less error prone is great. Yet, I didn't quite understand why using obj-c 2 garbage collection seems to completely remove manual memory management. If you're churning through a lot of large objects in a loop, for example, it seems like the garbage collector can easily need a second to catch up which may just unnecessarily add 100MB or so to your memory consumption. Which seems fairly unnecessary. I assume doing things this way simplified the background magic, but I still wonder how people handle such situations when using GC.

bbum writes: # If you're churning through a lot of large objects in a loop, # for example, it seems like the garbage collector can easily # need a second to catch up which may just unnecessarily add # 100MB or so to your memory consumption. Which seems fairly # unnecessary. First, the collector has improved over time. It is much more difficult to outrun the collector in Snow Leopard than Leopard and you can expect the trend to continue. In the rare case that you are allocating and deallocating a ton of memory, it is often the case that optimizing for reuse is the right answer, GC or non- (thrashing the heap with a ton of malloc/free events is painful regardless of memory management system used). And that is really the crux of it; by offloading memory management to the system, you give the system to optimally manage memory resources, well, systemically. This includes automatically reaping the benefits of performance optimizations that happen over time. For example, in Snow Leopard there are a handful of patterns that are actually quite a bit faster under GC than non. Expect *that* trend to continue, too, and those apps that are GC'd to get that much faster along with it.

Comment on this article: Name: E-Mail: (not shown, hashed for Gravatar) Web Site URL: (optional) Comment: (plain text only) Please Enter the following word:

Or E-Mail Uli privately.