On May 4, 2011, at 06:03, Joao Manuel Da Silva Neves wrote: > Apple's documentation states: "The process of migrating a large project that > uses reference counting can be difficult and error-prone—some patterns that > work correctly with manual memory management will be incorrect after > translation. In general, it is recommended that you use garbage collection > only in new projects. If you already have a well-architected, well-understood > application that uses reference counting, there should be little reason to > migrate to GC" > > Unfortunately we have a large project (think Apple's Aperture) that we're > considering for migration to GC in order to reduce memory crashers and > simplify memory management in the future. > Has anyone tried converting a large project to GC? If YES was it successful > and worth it? What were the main issues encountered during the conversion?
I threw away all my reference counting memory management I think 2 years ago, and for me it's definitely been worth it. It's not really the size of the project that's an issue, but the number of different memory-management subpatterns it uses. Going from retain/release (RR) to GC shouldn't be too hard. In my experience, the most significant problems were in relation to dealloc and finalize: -- Many RR applications use 'dealloc' not just as an intervention point to release an object's resources, but also as a kind of notification that the object's lifetime is ended. There's no real equivalent in GC, because by the time 'finalize' is called it's too late to make use of the information -- and you don't know exactly when 'finalize' is going to be called anyway. (A simple example: closing a std-lib-referenced file might work fine in 'dealloc', but if you try to do it in 'finalize' instead, you might end up running out of file descriptors if collection is deferred beyond the point of opening new files in other objects.) In a GC application, you might have to notify an object (via, say, some kind of 'releaseResources' method call) to release its resources *prior* to its becoming unreferenced. This can be a huge PITA, and sometimes the best solution is ... reference counting. So, in a few cases, you might want to use CFRetain/CFRelease or invent your own reference counting mechanism, since retain/release no longer does anything. Reference counting in a GC environment may *seem* odd, but it's a perfectly viable technique.*** -- You have to learn (usually the hard way) that inter-object messaging in 'finalize' is almost always doomed to failure, since you have no good way of knowing whether the messaged objects are alive, pending finalization or already finalized. This means you have to very carefully parse your existing 'dealloc' (and related code) to separate cleanup of GC-managed resources (such as objects), which typically need no explicit GC cleanup or must be cleaned up prior to 'finalize', from non-GC-managed resources (such as memory you've malloc'ed yourself), which should be cleaned up in 'finalize' (at least as a failsafe, even if they're intended to be cleaned up earlier). Given that part of your intention here is to expose poor application design in the existing code, I'll happily predict that converting to GC will indeed expose the problems. You may end up tearing your hair out at 2 am (an outcome from which Apple's documented advice is trying to save you), but it sounds like this is what you want. :) *** It's probably most effective to assume that collection might *never* occur. In theory, if your Mac had enough memory (petabytes), it wouldn't matter if you leaked everything, so you could have the most efficient GC of all -- no collection at all. AFAIK, there's no actual API contract about when, or if, GC occurs. Of course, it doesn't *actually* work like that. Mini-collection usually runs often, and full collection usually runs within 5 seconds, perhaps longer if the app is very CPU bound. But it's a useful mindset to have, to prevent you from thinking that GC can be used just like RR. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
