Re: NSAllocateCollectable() questions
Re: NSAllocateCollectable() questions
- Subject: Re: NSAllocateCollectable() questions
- From: Alastair Houghton <email@hidden>
- Date: Tue, 15 Apr 2008 15:18:30 +0100
On 15 Apr 2008, at 06:42, Brendan Younger wrote:
Hi all,
This is a re-post since I didn't receive any response on Sunday.
I've been writing a library that uses NSAllocateCollectable() quite
a bit and I have a few questions about proper usage.
The problem is that your questions are quite involved and so the only
people who can give a definitive answer at this point are the people
inside Apple who deal with the GC. Some of them do read the list, but
since the mailing lists are volunteer-based, and since there's a lot
of traffic and they're busy people, you might not always get their
attention.
- Copying data
if I am copying to a malloc'd block, I can use memmove() regardless
of whether the source is GC'd or not, right?
if I am copying to a GC block allocated with NSScannedOption, I need
to use objc_memmove_collectable(), right?
if I am copying to a GC block allocated with nonscanned memory, I
can use memmove(), right?
I *think* all three of these are correct. Obviously in the first and
last cases you don't want to have any pointers to GCable objects in
the memory concerned, as they won't be traced by the collector.
- Zero'ing data
There does not seem to be a GC-compatible bzero(). If I loop
through and zero out each pointer in a scanned block, that would
generate a write barrier for each pointer which is expensive.
However, if I use bzero(), then libauto won't know that I've messed
with the block. Will it eventually figure it out when it does an
exhaustive scan? Or will it never notice that I've zero'd out the
block?
I might be wrong, but I don't *think* libauto will care if you zero
something out; the problems arise when you write a pointer somewhere
without a write barrier, expecting the pointed-to object to remain
live. There are two problems that doing that can cause:
1. If you write into an object that's part of an older generation, in
which case the collector might not know that it needs to use this
pointer as a root when collecting younger generations.
2. If you write into an object that has already been scanned during
this GC cycle, in which case the collector won't know about the new
pointer.
In either case, the GC may as a result throw away a live object,
resulting in a later crash. Now I don't have access to the GC source
code, so there could be other potential problems also, but those are
the two common ones from the literature.
But like I say, you'll need someone from Apple to give you a
definitive answer on this.
FWIW there are a few other dangers with NSAllocateCollectable(). See
e.g.
<http://lists.apple.com/archives/cocoa-dev/2008/Feb/msg01530.html>
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