Hi all. I'm getting a crash in auto_zone_root_write_barrier() that
I don't understand. I suspect it has to do with this little blurb in
the Garbage Collection Programming Guide:
Limitations on Mac OS X v10.5: You may pass addresses of strong
globals or statics into routines expecting
pointers to object pointers (such as id* or NSError**) only if they
have first been assigned to directly, rather
than through a pointer dereference. You should never take the address
of a weak global, static or instance
variable, as assigning or reading through that pointer will bypass the
weak barriers and expose your programs
to race conditions.
But I'm not really sure. :-> Here's the situation. My app
generates floods of instances of an NSObject subclass called
AKIndividual. So many, in fact, that I don't want to alloc and
dealloc them all, as that just thrashes the allocator madly (as
verified with Sampler). Instead, I want to allocate a pool of them,
and then throw them in the pool when I'm done with them, and get new
ones out of the pool. (When I reuse them, I don't call -init again, I
just wipe the ivars I'm using and put new values in, which I believe
is OK.) When I'm messing about with them, and when they're in the
pool, I don't want to keep them in Cocoa collections like
NSMutableArray, because again that introduces too much overhead.
Countless billions upon billions of these little guys I'm making, and
the runtimes of my app will be measured in days to weeks, so
optimizing this bottleneck really is important.
So my solution was to keep pointers to them in malloced buffers
instead. The "unused pool" is a malloced buffer, the pools of ones
that are doing various things are also malloced buffers, and
everything is nice fast C code at this level. But I guess pointers to
objects kept in malloced buffers are weak references, so my objects
would be collected if I didn't have a strong reference somewhere. So
when I first allocate them, I throw them into an NSMutableArray, and I
don't ever take them out. That array is kept by the controller of the
whole shebang; so when that controller gets collected, then all the
individuals will be collected, but until then, they should always be
strong-referenced.
This seems like it ought to work; and yet I get that crash in
auto_zone_root_write_barrier(). After some puzzling, I found the
above paragraph in the GC guide. I am indeed on 10.5. Is this what's
biting me? I guess all the pointers to my AKIndividuals that are kept
in my malloced arrays are all weak references, and so I guess the
pointer to the malloced array itself, for example, is a pointer to a
weak reference such as I am not supposed to use, and whenever I do
something like "individuals[i]" to get an instance from my malloced
buffer I guess I'm violating the weak barriers. I find it hard to
believe that I'm not allowed to keep an array of pointers to objects,
though; is that really what this blurb is saying? (On the other hand,
the GC guide also says that "the malloc zone is never scanned", which
would imply that this is fine, and that the references I put in my
malloced arrays are not even weak; but then I'm puzzled by the crash
in a write barrier function...) I don't really understand what is
prohibited and exactly why; that blurb is way too short, and the
example is too short and cryptic. Can some explain what is actually
prohibited, and why, and whether what I'm doing is prohibited?
Given the architecture I'm aiming for, I don't need the references
to even be weak references; I don't need them to zero out, because
they never will, because these AKIndividuals live at least as long as
any given malloced array of them will live. Indeed, I don't care
about GC on them at all; I'd be quite happy to exclude them from the
GC scheme altogether, and get back the overhead of these read/write
barriers, given how much thrash is involved with them. Is that
possible? For example, can I malloc the instances of AKIndividual
myself out of the malloc zone to exclude them from GC, or is that a
Bad Idea?
Sorry for the long email. Comments?
Ben Haller
Stick Software
_______________________________________________
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 arch...@mail-archive.com
