Re: Transitioning to GC-supported
Re: Transitioning to GC-supported
- Subject: Re: Transitioning to GC-supported
- From: Greg Parker <email@hidden>
- Date: Mon, 26 Oct 2009 11:22:19 -0700
On Oct 26, 2009, at 6:45 AM, Dave Keck wrote:
3. Wrap all CF*Create(), CG*Create(), CF*Copy(), CG*Copy(), etc. with
CFMakeCollectable(), and replace corresponding CFRelease()s with a
custom
macro - CFReleaseIfRC(). (This way, if I ever choose to go GC-only,
I can
simply remove all calls to CFReleaseIfRC().)
This is more complicated.
If you use temporary CF objects, then CFCreate+CFRelease still works
just fine (assuming you trust your own l33t memory management skillz).
If you store CF objects in instance variables, this is one way to
handle it. Then you don't need CFReleaseIfRC().
ivar = NSMakeCollectable(CFCreate());
-dealloc: CFRelease(ivar)
-finalize: /* nothing */
4. Search for every call to -retain, -alloc, -init pairs, and -copy.
Verify
that the object being retained is strongly referenced, and if not,
it must
be CFRetain()ed or -disableCollectorForPointer: must be called for it.
Some of these references may be candidates for zeroing weak variables
instead.
5. Search for every call to -release and -autorelease. If the object
being
released is a CFType, then it must be CFReleaseIfRC() instead.
Beware of toll-free typecasts. CFRelease() must balance CFRetain(),
even if the type is actually `id`. Vice versa for -retain/-release of
CF types.
6. Search for every use of '&', and use objc_assign_global() and
objc_assign_ivar() as necessary.
You shouldn't need to do this. I don't remember when there last was a
known bug here, but Snow Leopard and the most recent gcc-4.2 ought to
be good. For a 64-bit screen saver you don't care about anything
earlier.
Some more suggestions:
* Beware of malloc allocations that store object pointers. They need
to be changed.
* CF containers with NULL callbacks that store object pointers are
almost always GC-unsafe. NSHashTable, NSMapTable, and NSPointerArray
can be configured as safe replacements.
* Use the leaks tools to catch malloc and CFRetain problems, and use
the Object Allocation instrument to look for GC leaks. A "GC leak" is
an object that you want to be dead but isn't, because something else
still has a pointer to it. Common examples are a pointer from a long-
lived controller to some other short-lived object that needs to be
explicitly set to nil, or a long-lived container to which objects are
added but never removed.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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