Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful

FROM : Jonathon Mah
DATE : Tue Feb 05 08:47:05 2008

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_removed>