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: Sun, 8 Jun 2008 08:40:49 +0100
Hi Peter,
On Sun, Jun 8, 2008 at 1:15 AM, Peter Duniho <email@hidden> wrote:
> Maybe it's just because I've been using GC systems more than you have, and
> so I've gotten used to thinking about memory allocations in the paradigm
> that GC systems impose.
I'm starting to realise that this is my barrier. I'm just an
Obj-C/Cocoa programmer who never had any objection to version 1 memory
management and is a bit alarmed to discover that I can't control the
scope of my objects' lifetimes as easily as I could with an
autorelease pool.
> That's because the root of this problem isn't the
> optimizing compiler. It's the fact that garbage collection is being used
> alongside other forms of memory management. It's only because there are
> things that are allocated outside of the garbage collection system that this
> even comes up.
Indeed, although I've used several other GC languages before, I've
never tried to mix GC with non-GC before.
>> The compiler is already in that business -- hence the modifiers
>> __strong and __weak.
>
> Not really. In fact, if anything those are proof that the compiler is _not_
> in the business of memory management. Instead, it provides a way for YOU to
> give it information that is used to control memory management. If the
> compiler were in the business of memory management, it would infer those
> properties itself.
I guess what I meant is: the compiler is in the business of telling
the GC what it can and cannot collect.
>>> and b) there will still be lots of other scenarios that
>>> are similar, but not solvable by the compiler.
>>
>> Could you please elaborate on this?
>
> I'm surprised I need to.
>
> But, consider the NSData example we've been using. Suppose that the byte*
> in question weren't just used locally, but rather passed to some other data
> structure. Even if we "fixed" the compiler so that it didn't optimize away
> the variable referencing the "data" object, when that variable goes out of
> scope as the method returns, the byte* still would potentially be released,
> as the "data" object is.
Yes, but this is nothing to do with the discussion at hand. We are
talking about the lifetime of the NSData object. This "inner pointer"
class of problems existed with autorelease, too, but because the
lifetime of autoreleased objects was deterministic, it was easier to
handle.
> No one said anything about _referencing_ "data". You have to _use_ it in a
> way that the compiler _can't_ rearrange.
Okay, I think I understand these usages now.
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