Re: Garbage collector vs variable lifetime
Re: Garbage collector vs variable lifetime
- Subject: Re: Garbage collector vs variable lifetime
- From: "Hamish Allan" <email@hidden>
- Date: Sat, 7 Jun 2008 23:37:10 +0100
On Sat, Jun 7, 2008 at 7:35 PM, Michael Ash <email@hidden> wrote:
> 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?
:)
I'm just arguing that it makes it more straightforward if the GC
behaves deterministically according to the code you wrote, rather than
what the optimising compiler re-wrote for you.
> 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.
I guess so! But it means that that promise is worth about as much as
an inner pointer ;)
>>> 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.)
Where is the problem with having NSData return collected memory? I
have no problem with that, I just don't think it solves the whole
problem.
Now it's your turn -- where is the problem with the compiler marking
references you have *semantically* placed on the stack as strong,
whether or not they really end up on the stack after optimisation?
> 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.
But who is to say the compiler won't make optimisations which alter
when the object is last referenced? (See my reply to Peter for a code
example.)
Hamish
_______________________________________________
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