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 07:34:25 -0400
On Sat, Jun 7, 2008 at 7:13 AM, Ken Thomases <email@hidden> wrote:
> Nobody is claiming that it should. It's not about the char* pointer. It's
> about the NSData* pointer.
Actually I think that it is about the char * pointer, and this bug
should be considered an NSData bug rather than a compiler bug or a GC
bug. The fact that it's really a design bug in NSData rather than
something that can be easily fixed definitely makes it worse, but
doesn't really change the location of the fault.
The GC basically guarantees you that objects which you continue to use
will continue to live until you're finished using them. Optimizations
don't affect this at all; the compiler can't optimize away the storage
of an object pointer until you're done using it. 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.
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.
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.
Perhaps the solution would be for the GC to allow for collected memory
with a custom allocator. This way NSData could always make the
internal memory be collected, using the custom allocator to properly
clean up for cases such as memory mapped files.
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