Re: NSAllocateCollectable() questions
Re: NSAllocateCollectable() questions
- Subject: Re: NSAllocateCollectable() questions
- From: "Clark Cox" <email@hidden>
- Date: Wed, 16 Apr 2008 09:04:00 -0700
On Tue, Apr 15, 2008 at 7:29 PM, Michael Ash <email@hidden> wrote:
> 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.
The purpose of the write barrier is to tell the collector to keep
something alive; it has nothing to do with when to collect it.
> This will result in a memory leak of sorts,
It will lead to an object being kept around for the current GC cycle.
However, the next time the collector scans, it will find that there
are no references left to that particular object, and it will then
collect it. This is the essential argument between supporters of
manual memory management and garbage collection:
Manual Memory Management:
I can know exactly when my object is destroyed, and I can count on
that fact (i.e. when I call free(), I know that that object is "gone"
immediately)
But it is complicated, and much of the housekeeping is easy to get wrong.
Garbage Collection:
The housekeeping is taken care of, I don't have to worry about it.
However, I cannot know exactly when my object will be destroyed (it
might be right away, it might be in a couple of seconds).
> 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?
--
Clark S. Cox III
email@hidden
_______________________________________________
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