I would avoid messing with the retainCount. Have you looked at using NSCache to retain the objects in your pool?
Other approaches that you could try: 1) Your central object pool has an array which holds a strong reference to the objects, and has a method (that can be called in a low-memory situation) which just empties the array. 2) Instead of having a central object pool, have the objects adhere to a protocol which takes a method to be called in low-memory situations which nils out things which can be reconstructed later and then calls the same method on objects lower in the graph. Thanks, Jon > On May 17, 2015, at 5:47 PM, Britt Durbrow > <bdurb...@rattlesnakehillsoftworks.com> wrote: > > 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 (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: > https://lists.apple.com/mailman/options/cocoa-dev/jhull%40gbis.com > > This email sent to jh...@gbis.com _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
