Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- Subject: Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
- From: Greg Parker <email@hidden>
- Date: Thu, 7 Feb 2008 20:30:29 -0800
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@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden