shanecrawford.org Home Grown in Austin

Patterns for garbage collection

Garbage collection in Leopard adds a new dimension to Mac development which allows developers to focus more on application functionality rather than on memory management. This nirvana, however, is not without some pitfalls. Knowledge of a few key concepts and traps to avoid should keep your application development humming along.

Patterns to use

• Actively manage resources.
  • Objects that manage resources such as socket connections, file descriptors, database connections, etc. should actively decommission those resources when they are no longer needed. Each object contains a finalize method which is run when the object is collected by the GC. However, there is no guarantee of when this method will be run. Therefore, decommissioning resources should not occur in the finalize method. Consider adding your own method to trigger decommissioning which can be called by your application when the object is no longer needed.
• Use fast enumerations to iterate over the contents of a collection.
  • If you use collections that support weak references (NSMapTable, NSHashTable, and NSPointerArray) then it is possible that garbage collection can occur during iteration thus potentially changing the Collection item count. This can cause an error if this occurs while iterating using a for loop. In order to avoid these issues iterate over Collections using the new Objective-C 2.0 Fast Enumeration syntax.
• Use the GC.
  • It may seem obvious but if your application can require Leopard and is not dependent on older frameworks and libraries then you really should consider using the garbage collector. The potential benefit to your own productivity is enormous in terms of time to develop, more stable software, and a better user experience.

Patterns to avoid

• Do not over-root objects.
  • While the GC frees you from most memory management tasks it is not a free ride. Memory leaks are still possible through objects that are unused but still attached to the main object graph. Care must be taken to ensure that strong references to these objects are cleared when they are no longer required (consider using weak references in some cases - more on this in a later post). Many times stray references to objects can occur when storing an object within a Collection data object (NSArray, NSDictionary, etc).
    
• Make no assumptions about the state of an object when its finalize method is called.
  • With reference counting some objects used the dealloc method to release deep subgraphs of objects. In some cases objects which referenced each other may have made assumptions about the state of the other object in order to walk the object subgraph in order to release resourced. With garbage collection this assumption cannot be made with usage of the finalize method. If such a necessary case exists then objects may need to implement a series of custom methods which can be called manually by the programmer when an object is no longer needed.

• Refrain from allocating large numbers of short lived objects.
  • Garbage collection does not make object allocation or deallocation any less expensive than reference counting memory management techniques. Reduce object proliferation when possible.

These are just a few of the primary usage patterns in a Cocoa garbage collected environment. An awareness and a quick check of them will help to make your apps even more stable and lead to a better user experience.

[…] Patterns for garbage collection Garbage collection in Leopard adds a new dimension to Mac development which allows developers to focus more on application functionality rather than on memory management. This nirvana, however, is not without some pitfalls. … […]