Re: NSAllocateCollectable() questions
Re: NSAllocateCollectable() questions
- Subject: Re: NSAllocateCollectable() questions
- From: Alastair Houghton <email@hidden>
- Date: Thu, 17 Apr 2008 11:43:04 +0100
On 16 Apr 2008, at 17:22, Michael Ash wrote:
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.
Ah, I see. Yes, you're right that write barriers have been used for
that kind of thing.
We've just had a number of posts recently where the assumption has
been that the write barrier was just a way of doing automatic
reference counting (or similar) behind the scenes.
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.
Not necessarily; there are other mechanisms that could be used to
implement that optimisation, for instance page table dirty bits.
Also, it might be possible in some cases to use the mincore() function
to avoid touching pages that have been swapped out. Another approach
might be to use the write barrier as a hint that objects need to be re-
scanned, and then periodically do a full scan to catch garbage that
has been created by non-write-barriered zeroing. Whether libauto/
Cocoa GC does any of those things I have no idea.
Also, the fact that the GC is generational, coupled with the fact that
it seems unlikely that you will create and retain many rarely-used
objects (if you were doing that, why not just release them?) means
that while theoretically a problem I don't believe the working set
size will be such a problem in practice. It might be in particular
types of programs, I suppose, but I think they would be atypical
applications for Cocoa.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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