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: j o a r <email@hidden>
- Date: Sun, 3 Feb 2008 23:18:06 -0800
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
_______________________________________________
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