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

FROM : Ben Trumbull
DATE : Mon Feb 04 10:19:42 2008

[and to the list]

You'll want to read this:

<http://developer.apple.com/documentation/Cocoa/Conceptual/GarbageCollection/Introduction.html
>

On the first page, it says:

"The initial root set of objects is comprised of global variables, 
stack variables, and objects with external references. These objects 
are never considered as garbage."

The key point here is "stack variables" include everything that thread 
is referencing on any of its stack frames or registers.

> This information is essentially impossible to know apriori,


No, it's not a quality of the dynamic allocation, it's a quality of 
the class's ivar.  Should title be scanned ?  Yes ?  No ?

Practically speaking, Objective-C objects are allocated from scanned 
memory, and the system frameworks Do The Right Thing.  If you call 
malloc() yourself, well, that's clearly not from GC's scanned memory.

> so the only practical course of action is to defensively qualify all 
> pointers as __strong.


That's probably wise for people learning to use GC.

> I believe I have a succinct example that illustrates these issues:


... you did it wrong and it doesn't work.  Check.

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


As it just so happens, I write a dual mode framework that does exactly 
that.

> This is beyond non-trivial in practice as the passing of pointers is 
> part of most functions calls.


Arguments and return values are always live as they are on the stack 
(or a register).  If one of those functions wants to store the pointer 
in its own memory, then you need to keep that pointer live for however 
long you expect the C library to reference it.  Which isn't any 
different than life before GC.

- Ben