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

FROM : Greg Parker
DATE : Fri Feb 08 05:30:29 2008

Ben Trumbull wrote:
> John Engelhart wrote:

>> - (id *)copyOfObjectArray:(id *)originalObjects length:
>> (NSUInteger)length
>> {
>> id *newObjectArray = NULL;
>> newObjectArray = NSAllocateCollectable(sizeof(id) * length, 
>> NSScannedOption);
>> memcpy(newObjectArray, originalObjects, sizeof(id) * length);
>> return(newObjectArray);
>> }

> This does not work. Pushing GC'd objects through memcpy, a system 
> call that can't know anything about Objective-C Garbage Collection, 
> seems unwise.


Correct. Don't manipulate memory that might have GC pointers in it 
without using a GC-aware function.


> Nonetheless, that also should be better documented, and a bug report 
> for a public GC compatible memory copy API would be good.


The GC-aware memcpy() is in <objc/objc-auto.h>

    void *objc_memmove_collectable(void *dst, const void *src, size_t 
size);

There are also GC-aware versions of OSAtomicCompareAndSwapPtr()

    BOOL objc_atomicCompareAndSwapGlobal(id predicate, id 
replacement, volatile id *objectLocation);
    BOOL objc_atomicCompareAndSwapGlobalBarrier(id predicate, id 
replacement, volatile id *objectLocation);
// atomic update of an instance variable
    BOOL objc_atomicCompareAndSwapInstanceVariable(id predicate, id 
replacement, volatile id *objectLocation);
    BOOL objc_atomicCompareAndSwapInstanceVariableBarrier(id 
predicate, id replacement, volatile id *objectLocation);

These are typedef'd as id, but they work equally well with any pointer.


>> Anyone who's used garbage collection with C is probably familiar 
>> with the Boehm Garbage Collector. [...] It makes no particular 
>> demands of the programmer or compiler, in fact it can be used as a 
>> drop in replacement for malloc() and free(), requiring no changes.


Of course, that only works if malloc() is replaced everywhere in the 
system, which is impractical in a dynamic shared library environment. 
Storing a Boehm-managed pointer in a block allocated from non-Boehm 
malloc() or a non-default malloc zone would cause just as much grief 
as storing a Leopard-GC-managed pointer in a block allocated with 
malloc().

The designer of a GC system always has to draw a line and say "if you 
cross this line, you have to start thinking about memory management 
again".
Java: memory management is easy, until you start working with non-Java 
code via JNI. Benefits: the JVM can use sophisticated GC techniques 
because of its tight control. Drawbacks: working with non-Java code is 
very hard.
Boehm: memory management is easy, until you call mmap() or start 
working with code in shared libraries. Benefits: most ordinary C code 
works. Drawbacks: GC algorithms invented after 1970 or so are 
impractical.
Objective-C: memory management is easy, until you want to use it with 
blocks that aren't Objective-C objects. Benefits: most ordinary 
Objective-C code works. Drawbacks: C code is harder than Boehm; GC 
flexibility is less than Java.


--
Greg Parker    <email_removed>    Runtime Wrangler