Re: Garbage collector vs variable lifetime
Re: Garbage collector vs variable lifetime
- Subject: Re: Garbage collector vs variable lifetime
- From: "Michael Ash" <email@hidden>
- Date: Sat, 7 Jun 2008 14:35:19 -0400
On Sat, Jun 7, 2008 at 10:31 AM, Hamish Allan <email@hidden> wrote:
> On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <email@hidden> wrote:
>
>> The business about scanning the stack is essentially an
>> implementation detail; the promise that is being made is that objects
>> which you're still pointing to won't go away.
>
> We're just interpreting this promise differently. To my mind, while
> the variable is still in scope, I *do* have a pointer to the object.
> It is available for my use until the end of that scope. The fact that
> I don't actually make use of it, and the optimising compiler thinks
> I'm done with it: *that*'s an implementation detail.
This is pretty nitpicky. If it's in scope but you don't use it, then
it doesn't matter. Kind of like a Zen koan: if an object is collected
in the forest but nobody is pointing to it anymore, does it make a
sound?
Objects stay live for as long as you reference them, period. This is
what the collector guarantees and this is what the real-world behavior
is. The problem occurs when you try to reference their contents after
you stop referencing the objects themselves. The documentation says
nothing about scope, it talks about the stack. The stack is already an
implementation detail, so if you're going to examine that promise then
you absolutely need to examine those implementation details.
>> How would it be less straightforward? If it returned collected memory
>> then everything will Just Work for the common case of using the
>> pointer on the stack. You would also have the additional convenience
>> of being able to safely store the returned pointer in a __strong heap
>> variable, something which you simply cannot do under non-GC rules at
>> all. Looks like there are only improvements to me, where is the
>> problem?
>
> I agree with you that if it returned collected memory, it would be
> more powerful than under retain/release/autorelease. But power and
> straightforwardness do not always go hand in hand ;)
Hmm, you didn't answer my question though. Where exactly is the
problem? For the case where the old-style rules also work, it would be
precisely as straightforward. (In case your objection is with the
__strong qualifier, note that you would not need that for a local
variable, only for instance variables.)
>> It *does* do this. The error is not in the GC, but rather in the
>> assumption that "declared in the current scope" is equivalent to "is
>> on the stack frame"
>
> Again, I see that as an implementation detail. From the documentation:
>
> "The root set is comprised of all objects reachable from root objects
> and all possible references found by examining the call stacks of
> every Cocoa thread."
>
> Given that the programmer cannot possibly know the state of the call
> stack any other way than by considering normal variable scoping rules,
> either it's meaningless to consider any variable on the stack as a
> root object, or the compiler needs to guarantee equivalence between
> them.
I disagree. Since the programmer cannot possibly know the state of the
call stack in any other way than by knowing that the compiler must
keep references to objects right up to the point where those objects
are no longer used, he must not make any assumption as to the lifetime
of those objects beyond that point.
Mike
_______________________________________________
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