On Tue, Apr 15, 2008 at 4:53 PM, Greg Parker <[EMAIL PROTECTED]> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
