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

FROM : Quincey Morris
DATE : Mon Feb 04 05:09:14 2008

On Feb 3, 2008, at 17:57, John Engelhart wrote:

> In order for leopards GC system to function properly, the compiler 
> must be aware of all pointers that have been allocated by the GC 
> system so that it can wrap all uses of the pointer with the 
> appropriate GC notification functions (objc_assign*).  Note that 
> this is subtly different that the definitions and examples used in 
> 'Garbage Collection Programming Guide'.  From 'Garbage Collection 
> Programming Guide', 'Language Support':
>
> __strong
> Specifies a reference that is visible to (followed by) the garbage 
> collector (see “How the Garbage Collector Works”).
>
> __strong modifies an instance variable or struct field declaration 
> to inform the compiler to unconditionally issue a write-barrier to 
> write to memory. __strong is implicitly part of any declaration of 
> an Objective-C object reference type. You must use it explicitly if 
> you need to use Core Foundation types, void *, or other non-object 
> references (__strong modifies pointer assignments, not scalar 
> assignments).
>
> ----
>
> This is a deceptive description.  /ANY/ pointer that holds a pointer 
> to memory that MAY be allocated from the garbage collector must be 
> marked __strong.  The compiler attempts to 'automagically' add 
> __strong to certain types of pointer references, specifically 'id' 
> and derivatives of 'id', namely class pointers (NSString *).


Interesting post. A couple of comments (that may just show I didn't 
absorb all of your argument):

-- The extent of the deception seems to be that __strong is an 
attribute of the declaration, not of the pointer, but the 
documentation confuses the two: the compiler must be aware of all 
*variables used for* pointers that have been allocated by the GC 
system, and *a single variable cannot be used at different times for 
pointers to memory in different allocation systems*. If there was a 
fix to the documentation, would you still say GC is broken?

-- It doesn't exactly surprise me that your sample code failed, 
because my reading of the documentation (the section you quoted) is 
that it told you the rules and you didn't follow them -- by not 
putting __strong on the char* ivar in the version that failed. The 
only issue is whether -[NSString UTF8String] returns memory allocated 
from a GC-controlled pool or not. The documentation for the method says:

> Discussion
>
> The returned C string is automatically freed just as a returned 
> object would be released; you should copy the C string if it needs 
> to store it outside of the autorelease context in which the C string 
> is created.


This sounds like it hasn't been updated for Leopard, but I'd sure read 
it as telling me the return string comes from the same place objects 
come from -- GC memory. And therefore any stored pointer to it would 
need a __strong or a __weak on its variable. Or, as stipulated, the 
result could be copied into malloc memory before being used. (The 
picture in the GC documentation suggests that malloc memory isn't GC-
controlled, although I didn't find any text to state this absolutely. 
Maybe it's too obvious to say.)

Or did I miss your point?

-- I too puzzled over the meaning of the stuff in the GC document 
about write barriers, which I agree raises more questions than it 
answers. In the end, I came to the conclusion that "write barriers" in 
this case were nothing to do with protecting the integrity or lifetime 
of any pointer, but rather a pragmatic hint to *this* GC 
implementation about how hard it might work at collection on any given 
occasion.

If the documentation were changed to use the phrase "collection 
performance hints" instead of "write barriers", would you still say GC 
is broken?

-- So I wonder if the problem is that GC is broken, or just annoyingly 
fussy and poorly documented as regards to non-object memory.

I hope you'll post more analysis of the problem. I (with a sigh of 
relief) jumped ship from the SS Retainer, so it matters to me if I'm 
now sailing towards that world of hurt you foreshadow. :)