Re: Tracking the retain count
Re: Tracking the retain count
- Subject: Re: Tracking the retain count
- From: Quincey Morris <email@hidden>
- Date: Mon, 18 May 2015 01:10:19 +0000
On May 17, 2015, at 17:47 , Britt Durbrow <email@hidden> wrote:
>
> 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.
I think you are on the right track with this, but instead of partitioning the objects into two containers, put all the objects in one container.
Specifically, keep a strong reference and a weak reference to each object. (You can use a NSMutableDictionary and a weak-valued NSMapTable.) Normally, when populating your cache, put similar references to each cached object into each container. When memory pressure requires, throw away the mutable dictionary, and all unreferenced objects will disappear from the map table. As soon as memory pressure goes away, rebuild the dictionary from the current state of the map table.
You can also do something similar with a single container, whose values are “pointer” objects that contain a strong and a weak reference to the same object. In that case you would nil out the strong reference under memory pressure, but there may be housekeeping to clean up unused “pointer” objects later.
If you’re prepared to go for a slightly uglier implementation, you can also do it with a single weak-valued container, where you manually increment the retain count (once) of each object referred to. Under ARC, this has to be done by code in a separate file that isn’t compiled under ARC, or you can get the same effect by bridging to Core Foundation and using CFRetain/CFRelease. In this scenario, you’d simply decrement all your manual retain counts when memory pressure occurs, then increment them later to restore the “extra” retain count.
_______________________________________________
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