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 09:18:39 -0400
On Sat, Jun 7, 2008 at 8:47 AM, Hamish Allan <email@hidden> wrote:
> On Sat, Jun 7, 2008 at 12:34 PM, Michael Ash <email@hidden> wrote:
>
>> The problem here is
>> that you're expecting one pointer to keep a *different* pointer live,
>> which the GC does not make any guarantees about.
>
> Pre garbage collection, this was straightforward: as long as you
> retain your NSData, the pointer returned by [thatData bytes] is valid.
>
> Post garbage collection, you would expect the rule to be equivalent:
> as long as you have a strong reference to your NSData, the pointer
> returned by [thatData bytes] is valid.
>
> Until the stack frame is popped, you have a strong reference to your
> NSData. Unless of course the compiler thinks it knows better. But I
> agree with Ken: the compiler is wrong.
What I'm saying is that the compiler+GC only guarantees that you have
a strong reference to that object *while you're using it*. It's very
easy to take the documentation and make a small leap to say that you
have a strong reference to an object for as long as the function where
the pointer is declared is on the stack, but that's not actually what
it says. 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. Once you pass the last
reference to an object, all bets are off.
>> Basically, under GC, my impression is that it should be considered
>> invalid to return a pointer to a caller which depends on the lifetime
>> of the parent object. In this case, for example, NSData really should
>> be returning a pointer to collected memory, so that instead of having
>> to pull dirty tricks to keep the NSData pointer alive, you can just
>> pull regular easy tricks to keep the char * pointer alive.
>
> Even if the NSData returned collected memory, it would still be less
> straightforward to use GC than pre-GC memory management. I thought GC
> was supposed to make memory management easier?!
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?
> All we really need is for the GC to behave as documented: treat an
> object whose variable is on the stack frame as a root object.
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". This assumption is not valid. The fact that you
can't make this assumption is extremely inconvenient for the situation
being discussed, but that doesn't mean that it's not behaving as
documented.
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