Re: Garbage collector vs variable lifetime
Re: Garbage collector vs variable lifetime
- Subject: Re: Garbage collector vs variable lifetime
- From: Ken Thomases <email@hidden>
- Date: Sat, 7 Jun 2008 06:13:54 -0500
On Jun 7, 2008, at 12:03 AM, Bill Bumgarner wrote:
On Jun 6, 2008, at 9:16 PM, Ken Thomases wrote:
And... we're back to retain/release.
The issue is, how can one know when this technique is necessary?
The supposed rules of GC are, if it's in a stack variable, it's
safe. The compiler here is doing something behind the programmer's
back, which the programmer can't really predict, that's changing
the rules.
Quoting the Garbage Collection Programming Guide: "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"
For some values of "never".
Objective-C 2.0's garbage collection system is incompatible with
any optimization which changes which variables are on the stack.
More accurately, it's an error if compiler optimizations change
what are considered root objects.
The problem here is that there is no way for the compiler to know
that the char* bytes is somehow connected to the lifespan of the
NSData*. Nor is there any way for the collector to know that the
char* bytes is somehow an implied root of the NSData* object.
Nobody is claiming that it should. It's not about the char* pointer.
It's about the NSData* pointer.
The compiler isn't changing roots and it isn't doing anything that
is a bug
It is and it is, depending on the meaning of "on the stack". See below.
-- it is merely optimizing the code to use the resources available
by recycling bits of memory that refer to items that, given all
knowledge that it has, are no longer needed.
I disagree. The problem is that there are two possible meanings of
"on the stack". In the sense that the GC system means, the phrase is
effectively meaningless. It's discussing details of the emitted
object code, which the programmer has no clear way of anticipating
with the current compiler, let alone future compilers.
What the programmer can see, and what s/he can control, is the scope
of automatic local variables. Many programmers probably assume that's
what the GC documentation means -- that if a variable is in scope,
then it's in the root set. Evidently, that's not what it means. You
could argue that means the programmer is mistaken. I argue that means
that the design of the GC system or of the compiler is, uh, less than
perfect. As things stand, programmers have to defensively apply
"voodoo" code practices (e.g. adding otherwise unnecessary [data self]
calls) to avoid unpredictable results.
This is exacerbated by the fact that the NSData* _is_ on the stack so
long as optimizations are turned off, but isn't when they're turned
on. Turning on optimizations should not change the correctness of code.
The GC system rules need to be not just technically accurate, but
offer practical guidance to programmers that doesn't require them to
understand what the compiler is doing or might do. "Practical" as in
"may be put into practice". Guidance about variable scope is
practical. Guidance about characteristics of the emitted object code
is not, in my opinion.
Regards,
Ken
_______________________________________________
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