Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- Subject: Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- From: Jonathon Mah <email@hidden>
- Date: Tue, 5 Feb 2008 18:17:05 +1030
Hi John,
I think I have an idea of how your expectations differ from the design
goals of "auto". You're expecting the GC to take over memory
management for the entire process, whereas libauto is designed to
handle the memory management of only the Objective-C side of things
(that is, objects). That is, libauto is _not_ a replacement for
malloc()/free(), but only for -retain/-release (simplistically). I
presume Apple chose this so that existing C libraries using malloc()/
free() would work identically.
For GC to work with ObjC objects whilst keeping vanilla malloc
behavior unchanged, the system has to make some assumptions. This
brings up issues where objects and void* meet. As the documentation
says (and as you've discovered), the rules are:
• For GC-allocated memory, void* references stored in globals and on
the stack are considered strong.
• For GC-allocated memory, void* references stored in objects are
ignored by default.
• For malloc-allocated memory, void* references stored anywhere are
unchanged.
(By void* I mean any non-id pointer, including const char *.)
I don't know why the second rule was chosen (having the GC ignore
undecorated void* ivars), and I haven't had enough experience with it
to know if it's a good or bad thing. But you certainly need to be
aware of it if you're used to a purely-GC environment, as auto
provides a mixed malloc/GC environment.
So there are new conventions for Leopard's GC. I'll attempt to start a
list here, but don't take it as fact until there has been some peer
review.
• If you get a non-object pointer from somewhere (e.g. returned by -
[NSString UTF8String]), you need to know if it has been allocated in
the GC zone or the malloc zone. (The documentation "should" tell you
which.)
- If it's in the GC zone, you need to store the pointer in a strong
instance variable if you want it to stick around for more than the
current stack frame.
- If it's in the malloc zone, store it anywhere, but it's your
responsibility to free() it.
(Anything else?)
Jonathon Mah
email@hidden
_______________________________________________
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