Re: Understanding objc_assign_strongCast
Re: Understanding objc_assign_strongCast
- Subject: Re: Understanding objc_assign_strongCast
- From: David Elliott <email@hidden>
- Date: Thu, 7 Feb 2008 02:50:16 -0500
Hi Ben,
Thank you for your response. It is most helpful to know that CFRetain/
CFRelease are the most appropriate option for maintaining strong
references from non-GC objects and that objc_assign_strongCast has
zero effect unless the pointer itself is located in a GC-managed
heap. I've observed first-hand that it has zero effect in global
memory and zero effect in non-GC heaps and from my understanding ought
not to be needed on the stack. Did I miss any other notable types of
memory?
Now that you mention CF objects it occurs to me that
objc_assign_strongCast is intended for i-vars of CF objects located in
GC-managed heap. Or to put it another way, it is less related to
objc_assign_global and more like objc_assign_ivar for i-vars that are
in POD structs allocated in GC-managed heap. Some time in the future
I may endeavor to push the limits of this theory as it sounds quite
tempting to apply the GC to other code.
The only remaining question I have pertains to compatibility with
prior OS X versions. Clearly CFRetain/CFRelease work on Leopard. And
as far as I know code with GC-write barriers can only work on Leopard,
even when it is compiled to support both RR and GC, due to the simple
fact that the objc_assign_* series of functions do not exist on older
versions of OS X.
Keep in mind I am writing a library (wxCocoa) that must work in both
RR and GC mode. Therefore my usage of CFRetain/CFRelease will be
balanced appropriately so as to function at runtime correctly
regardless of mode. However, if compiling for pure-RR mode is it
still reasonable to use CFRetain/CFRelease in lieu of retain/release
or will this cause me problems when targeting older versions of OS X?
Do I need to condition CFRetain/CFRelease on garbage collection being
potentially supported or is it safe to just judiciously replace retain/
release with CFRetain/CFRelease and expect the same code to run on
prior versions of OS X?
Hopefully I understand enough now and hopefully your reply will prove
useful in the archives to other people. Again, thanks for the response.
-Dave
On Feb 6, 2008, at 8:23 PM, Ben Trumbull wrote:
Dave,
objc_assign_strongCast() will issue a write barrier, informing GC
that the destination value has changed. But if the only references
to this pointer are in unscanned (not GC) memory, than the GC system
will think it's dead as no references to that pointer exist in
scanned (GC live) memory.
The C++ new operator allocates from malloc(), just as before.
malloc() memory is not GC scanned. It's probably easiest to instead
use CFRetain and balance it with CFRelease in delete/etc.
In fact, I've written some pretty hairy hybrid memory model code,
and have yet to find a use for calling objc_assign_strongCast()
myself.
The GC programming guide talks about using CFRetain/CFRelease in the
section on Core Foundation objects. The primary difference with C++
objects is that C++'s new is from unscanned malloc memory where as
CF types (with the default allocator) are allocated from scanned
memory.
--
-Ben
_______________________________________________
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