Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: Jonathan Hull <email@hidden>
- Date: Sun, 17 May 2015 18:14:44 -0700
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 <email@hidden> 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 (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