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: Quincey Morris <email@hidden>
- Date: Sun, 3 Feb 2008 20:09:14 -0800
On Feb 3, 2008, at 17:57, John Engelhart wrote:
In order for leopards GC system to function properly, the compiler
must be aware of all pointers that have been allocated by the GC
system so that it can wrap all uses of the pointer with the
appropriate GC notification functions (objc_assign*). Note that
this is subtly different that the definitions and examples used in
'Garbage Collection Programming Guide'. From 'Garbage Collection
Programming Guide', 'Language Support':
__strong
Specifies a reference that is visible to (followed by) the garbage
collector (see “How the Garbage Collector Works”).
__strong modifies an instance variable or struct field declaration
to inform the compiler to unconditionally issue a write-barrier to
write to memory. __strong is implicitly part of any declaration of
an Objective-C object reference type. You must use it explicitly if
you need to use Core Foundation types, void *, or other non-object
references (__strong modifies pointer assignments, not scalar
assignments).
----
This is a deceptive description. /ANY/ pointer that holds a pointer
to memory that MAY be allocated from the garbage collector must be
marked __strong. The compiler attempts to 'automagically' add
__strong to certain types of pointer references, specifically 'id'
and derivatives of 'id', namely class pointers (NSString *).
Interesting post. A couple of comments (that may just show I didn't
absorb all of your argument):
-- The extent of the deception seems to be that __strong is an
attribute of the declaration, not of the pointer, but the
documentation confuses the two: the compiler must be aware of all
*variables used for* pointers that have been allocated by the GC
system, and *a single variable cannot be used at different times for
pointers to memory in different allocation systems*. If there was a
fix to the documentation, would you still say GC is broken?
-- It doesn't exactly surprise me that your sample code failed,
because my reading of the documentation (the section you quoted) is
that it told you the rules and you didn't follow them -- by not
putting __strong on the char* ivar in the version that failed. The
only issue is whether -[NSString UTF8String] returns memory allocated
from a GC-controlled pool or not. The documentation for the method says:
Discussion
The returned C string is automatically freed just as a returned
object would be released; you should copy the C string if it needs
to store it outside of the autorelease context in which the C string
is created.
This sounds like it hasn't been updated for Leopard, but I'd sure read
it as telling me the return string comes from the same place objects
come from -- GC memory. And therefore any stored pointer to it would
need a __strong or a __weak on its variable. Or, as stipulated, the
result could be copied into malloc memory before being used. (The
picture in the GC documentation suggests that malloc memory isn't GC-
controlled, although I didn't find any text to state this absolutely.
Maybe it's too obvious to say.)
Or did I miss your point?
-- I too puzzled over the meaning of the stuff in the GC document
about write barriers, which I agree raises more questions than it
answers. In the end, I came to the conclusion that "write barriers" in
this case were nothing to do with protecting the integrity or lifetime
of any pointer, but rather a pragmatic hint to *this* GC
implementation about how hard it might work at collection on any given
occasion.
If the documentation were changed to use the phrase "collection
performance hints" instead of "write barriers", would you still say GC
is broken?
-- So I wonder if the problem is that GC is broken, or just annoyingly
fussy and poorly documented as regards to non-object memory.
I hope you'll post more analysis of the problem. I (with a sigh of
relief) jumped ship from the SS Retainer, so it matters to me if I'm
now sailing towards that world of hurt you foreshadow. :)
_______________________________________________
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