---

Adopting Garbage Collection

Garbage collection provides trade-offs that you need to consider when choosing whether to adopt the technology.

Potentially, any application that uses a runloop may use garbage collection, however there are issues you should consider when deciding whether it is appropriate for your application. Garbage collection provides several advantages when compared with manually managed memory; there are also, though, some disadvantages. The benefits tend to be greater if the application is threaded and has a reasonably large working set; they tend to be less if the latency of memory recovery is important. Moreover, managed memory and garbage collected applications use a number of different idioms and patterns.

For information relating to garbage collection in the current release of Mac OS X, see Garbage Collection Release Notes.

Contents:

Advantages and Disadvantages
Performance

Advantages and Disadvantages

Garbage collection offers some significant advantages over a managed memory environment:

• Most obviously, it typically simplifies the task of managing memory in your application and obviates most of the memory-related problems that occur, such as retain cycles.

• It reduces the amount of code you have to write and maintain, and may make some aspects of development easier—for example, zeroing weak references facilitate use of objects that may disappear.

• It usually makes it easier to write multi-threaded code: you do not have to use locks to ensure the atomicity of accessor methods and you do not have to deal with per-thread autorelease pools. (Note that although garbage collection simplifies some aspects of multi-threaded programming, it does not automatically make your application thread-safe. For more about thread-safe application development, see Threading Programming Guide.)

Garbage collection does though have some disadvantages:

• The application’s working set may be larger.

• Performance may not be as good as if you hand-optimize memory management (for more details, see “Performance”).

• A common design pattern whereby resources are tied to the lifetime of objects does not work effectively under GC.

• You must ensure that for any object you want to be long-lived you maintain a chain of strong references to it from a root object, or resort to reference counting for that object.

Performance

The performance characteristics of an application that uses garbage collection are different from those of an application that uses managed memory. In some areas, a garbage-collected application may have better performance, for example:

• Multi-threaded applications may perform better with garbage collection because of better thread support;

• Accessor methods are much more efficient (you can implement them using simple assignment with no locks);

• Your application is unlikely to have leaks or stale references.

In other areas, however, performance may be worse:

• Allocation may be a significant consideration if your application allocates large numbers of (possibly short-lived) objects.

• The working set may be larger—in particular, the overall heap can grow larger due to allocation outpacing collection.

• The collector scans heap memory to find reachable objects, so by definition keeps the working set hot. This may be a significant consideration, particularly if your application uses a large cache.

• The collector runs in a secondary thread. As such, a GC-enabled application will in almost all cases consume more CPU cycles than a managed memory application.

When analyzing the performance of a garbage-collected application, you typically need to take a longer-term approach than with a managed memory application. When assessing its memory footprint, it may be appropriate to measure after the application has been running for several minutes since the memory footprint may be greater shortly after launch. The profiling tools you can use include heap, gdb flags, and the Instruments application.

---