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

FROM : j o a r
DATE : Mon Feb 04 08:18:06 2008

Hello John,

On Feb 3, 2008, at 5:57 PM, John Engelhart wrote:

> This is bound to be an inflammatory subject.  That is not my intent, 
> and I mean no disrespect to the programmers who worked on the GC 
> system.  I'm quite sure that adding GC to Cocoa is a non-trivial, 
> near impossible task, filled with trade-offs between "really bad" 
> and "even worse."  Also understand that a bit of 'authoritative' 
> documentation or instruction can out right negate some of the points 
> I make below as I have had only the publicly available documentation 
> and my (relatively brief 2-3 months) experiences with the 10.5 GC 
> system to form these opinions....



Given that GC in Leopard is a 1.0 release I think it's to be expected 
that there will be bugs and room for improvement in both the 
implementation and the documentation. The best way to get the 
improvements that matters the most to you is to file targeted bug 
reports and enhancement requests.


> Anyone who's used garbage collection with C is probably familiar 
> with the Boehm Garbage Collector.  [...]
> From what I've pieced together, Leopards GC system is nothing like 
> this.



I think that the current "Architecture" section of the documentation 
gives a fairly good introduction and overview to what most developers 
need to know about the GC in Leopard. That said, I'm sure that you can 
think of things that you would like to see improved, and I encourage 
you to file enhancement requests wherever you do. The documentation 
department is very responsive and typically release multiple updates 
to the documentation per year.

As an example: The documentation currently basically only deals with 
Cocoa and CoreFoundation. It seems to me that you think that it's not 
clear enough on how to deal with for example a (char *), and I would 
agree. This would be a great enhancement request.


> This would explain the need for 'dual mode' frameworks, and that an 
> application that uses GC must be linked to frameworks that are all 
> GC capable.  This is because a non-GC framework would not actively 
> inform the GC system of its use of pointers, leading to random 
> crashes and what not as the GC system reclaimed memory that was 
> actively in use.



Manual memory management and automatic memory management is 
sufficiently different that you need to change your coding patterns to 
adapt to either mode. I don't think that you could point to any 
environment where you can run non-trivial code in either manual or 
automatic memory management without changes.

Finalizers have a different purpose in life than dealloc methods. You 
can't automatically turn dealloc methods into finalizers, and you 
can't just skip over them either. You need to have different code 
paths depending on the mode you choose for your code.


> And herein lies the reason why I believe Leopards GC system is 
> fundamentally and fatally flawed, and should in fact not be used at 
> all.  There are several possible 'solutions' to this, but you'd 
> better get it right or you're going to be stuck with race conditions 
> of the most insidious nature imaginable.  Adding fuel to the fire, 
> it's not clear what the 'right' solution is, or if there even is one.



Not to say that the engineers at Apple never make any mistakes, but do 
you really think that Apple would release something like this if what 
you say was true?  :-)


> One might argue that, per the __strong documentation, the ivar 
> requires the __strong type qualifier.  This is, at best, non-
> obvious, and considering that the documentation makes references to 
> 'objects' almost exclusively, one can also argue that this pointer 
> does not qualify.  But this points to a much bigger problem:  anyone 
> who has used UTF8String and not qualified it as __strong has a race 
> condition just waiting to happen.  This is also not a problem that 
> can be fixed with a patch to Foundation in the next Mac OS X 
> version- every program that has not qualified their use of 
> UTF8String with __strong must be recompiled and re-released as there 
> is nothing a shared library fix can do about this.



As a generalization I think it's fair to say that Apple will only fix 
bugs in *their* code by updates to Mac OS X, any bugs in *your* code 
must be fixed by you. If you have made a GC bug in one of your 
shipping applications - because you lacked sufficient documentation to 
get it right, or for any other reason - it's quite likely that you 
will have to issue an update to fix that bug.


> [...] A consequence of all of this is that you must not pass 
> pointers that may have been allocated by the garbage collector to 
> any C function in a library.  For example,
>
> printf("String: %s\n", [@"Hello, world!" UTF8String]);
>
> passes a GC allocated pointer to a C library function, which almost 
> assuredly does not have the proper write barrier logic in place to 
> properly guard the pointer.  This example is innocent enough, and 
> likely to work due to its short lived nature, but it's easy to think 
> of examples where the pointer passed to a C function, say an SQLite3 
> call, can cause no end of problems if that pointer happens to be 
> reclaimed in the middle of the function call.



I think that you forget, and this might be at the heart of your 
worries, that any pointer found on the *stack* is treated as a root. 
Being a root it will not be collected, and neither will anything that 
it in turn references.


Cheers,

j o a r