Tracking the retain count
Tracking the retain count
- Subject: Tracking the retain count
- From: Britt Durbrow <email@hidden>
- Date: Sun, 17 May 2015 17:47:56 -0700
Ughh… I find myself in a bit of a quandary:
I have a pool of disk-backed (well, flash-backed on iOS) objects that have an arbitrary graph structure. These are managed by a central object pool. The object pool is supposed to cache these in memory (creating them is somewhat non-trivial), and hold onto ones that it’s been told to even if there are no other objects that currently have an active pointer to them outside of the pool’s object graph (consequently, just using weak links won’t work for my problem).
In order to respond to iOS memory pressure warnings, I need to have the object pool de-construct and release any graph segments that are not currently being used outside of the object pool. However, this needs to happen only during a memory pressure event, and not otherwise.
The only thing I’ve been able to come up with so far is somehow tracking the retain count state of the objects in the object pool, and when a memory pressure event occurs having the object pool find all the objects that are only in use in the graph and held by itself, and release them. Once all the otherwise unused objects have been converted via an isa swizzle to faults (and thusly no longer contain retain cycles), the faulted objects that are candidates for release should have a retain count of 1… at which point I can have the pool remove them from it’s main NSMutableDictionary (which will now cause them to be deallocated).
This, however, is kinda ugly… and known to be prone to pitfalls... but is there any better way?
Note that I don’t want to just use CoreData. Also, I did think of having the objects in the graph that are supposed to be held on to be held in a strong container, and the objects not currently being held on to in a weak container, but that doesn’t work because then the objects in the weak container will get purged when immediately, not just under a memory pressure event.
So what I’m looking at now is creating an intermediate base class for all of these objects, that is compiled with ARC turned off, and provides access to retainCount. Yes, I know that it doesn’t reflect any autoreleases that have occurred on the object. This is OK as far as I know - for this specific use, if something has an outstanding autorelease on an object, it’s probably OK to keep it around, as long as enough of the cached objects get purged to satisfy the memory pressure event. Also, this object pool is not guaranteed to be thread-safe so I don’t think that the potential race conditions of retain/release/autorelease/retainCount interaction will come into play.
Any ideas? Comments? Rotten tomatoes? :-)
_______________________________________________
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