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 13:47:32 +0100
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.
> 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?!
> The problem with this is that it's incompatible with the idea of
> wrapping different types of pointers, such as memory mapped files.
> That's why I refer to it as a design flaw rather than a simple bug to
> fix.
>
> Unfortunately I don't know what the solution would be. Under the
> old-style rules, the lifetime for an NSData object would be fairly
> predictable (previous examples in this thread have brought up release
> messages being sent by other threads, but this would be wholly invalid
> usage to begin with) thus it was safe to work with a pointer whose
> lifetime was completely tied to it. Now the lifetime is not
> predictable in the general case, even if you do everything else right,
> so you have to work to make it be predictable.
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.
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