Re: NSAllocateCollectable() questions
Re: NSAllocateCollectable() questions
- Subject: Re: NSAllocateCollectable() questions
- From: "Michael Ash" <email@hidden>
- Date: Wed, 16 Apr 2008 12:22:34 -0400
On Wed, Apr 16, 2008 at 5:28 AM, Alastair Houghton
<email@hidden> wrote:
> On 16 Apr 2008, at 03:29, Michael Ash wrote:
> > 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.
>
> No. The garbage collector does not use reference counting, and so your
> statement is not true. If you overwrite the last pointer to an object with
> a nil, the pointed-to object *may* survive the current garbage collection
> cycle, but it will not survive the next one.
It has nothing to do with reference counting. I thought that the
collector was using write barriers as a shortcut to knowing when a
block of memory was modified so that it could avoid constantly
re-scanning unchanging blocks. But now I see that it's only a
mechanism to avoid stopping all threads while scanning. This is kind
of disappointing because it means that an application which uses GC
must necessarily have its working set equal to the sum total of all
scanned memory plus the working set in any unscanned memory, but what
can you do.
Thanks for the links.
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