Re: GC crash due to being naughty
Re: GC crash due to being naughty
- Subject: Re: GC crash due to being naughty
- From: Ben Haller <email@hidden>
- Date: Thu, 15 Oct 2009 19:29:49 -0400
That looks like it is more a matter of decreasing memory usage than
decreasing alloc/dealloc/containment overhead. "A flyweight is an
object that minimizes memory use by sharing as much data as possible
with other similar objects; it is a way to use objects in large
numbers when a simple repeated representation would use an
unacceptable amount of memory." So I don't think it applies to my
problem.
Thanks though!
Ben Haller
Stick Software
On 15-Oct-09, at 7:14 PM, Oftenwrong Soong wrote:
Hi Ben,
Have you considered the so-called Flyweight design pattern? It is
designed to solve the problem of having a zillion objects to
allocate. It sounds like this pattern might prevent your having to
play the dirty tricks that are causing you problems.
In the frameworks, Flyweight is used, AFAIK, in NSNumber, NSCell,
and other classes. There's a good description of the pattern here:
http://en.wikipedia.org/wiki/Flyweight_pattern
Hope this helps a little. (I don't know what could be done to solve
the crash you describe but passing pointers as you described sounds
like it's bound to cause nasty problems.)
Soong
----- Original Message ----
From: Ben Haller <email@hidden>
To: Cocoa List <email@hidden>
Sent: Thu, October 15, 2009 3:54:11 PM
Subject: GC crash due to being naughty
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 (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
_______________________________________________
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
_______________________________________________
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