Re: NSAllocateCollectable() questions
Re: NSAllocateCollectable() questions
- Subject: Re: NSAllocateCollectable() questions
- From: "Michael Ash" <email@hidden>
- Date: Tue, 15 Apr 2008 22:29:06 -0400
On Tue, Apr 15, 2008 at 4:53 PM, Greg Parker <email@hidden> wrote:
> You don't need a write barrier when erasing GC-scanned memory. The write
> barrier helps the collector see pointers that it might otherwise miss
> because it's cheating. It does not help the collector "forget" a value that
> it saw previously. (In particular, the old pointer value might be gone from
> the zeroed location, but without re-scanning everything there's no way to
> know that it doesn't still exist somewhere else.)
If this is the case then how does the collector know that you have
cleared the memory. It seems to me that without a write barrier, the
collector will not see the change and will think that that you
continue to hold the old pointer in this memory. This will result in a
memory leak of sorts, although it can't really grow without bound in
most scenarios. But still, the collector needs to know when you nil
out a variable so that it can know that a particular link no longer
exists, just like it needs to know when you store a non-nil value so
that it can know that a new link now exists.
In other words, not using a write barrier for nil isn't a disaster but
it can cause garbage to fail to be recognized as such.
What did I miss?
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