On May 19, 2015, at 15:50 , Graham Cox <graham....@bigpond.com> wrote: > > I may have misunderstood the problem such that this is a poor ot for other > reasons, but I’m not seeing it. I’m also not sure why there seems to be a > tacit resistance to it - seems logical to me.
I don’t think you’ve misunderstood anything at all. I’ve hung back from replying for a bit, because I was not sure what to say next. Yesterday, I tried to retreat to firm ground and proceed from there, but apparently I didn’t do that very well. I’m going to try the same strategy one more time, to see if I can get onto even firmer ground, and stay there. I want to go back to Roland’s scenario, since it’s simple and contains the essence of what Britt wants to do. Let’s say we implement a cache as a strong-to-weak NSMapTable. That allows objects that are unreferenced (un-strong-referenced) elsewhere in our code to be purged. However, this is not the complete solution, because we want unreferenced objects to persist as long as they can, and a mere weak reference won’t achieve that. So, we look at two possible solutions. [Spoiler: Both solutions are 100% correct, because both solutions are 100% identical, as far as memory management is concerned.] Solution A: We create an additional strong reference to each object in the cache, kept in (say) a Cocoa collection. That allows us to selectively mark objects purgeable by removing some or all of these strong references. Drawback: We’re wasting memory for storing the additional strong references. Solution B: We retain each object as it enters the cache. That allows us to selectively mark objects purgeable by releasing them again. Drawbacks: None. The end. Note that there’s no objection (in either solution) on the basis of shaky reasoning about retain counts, because retain counts don’t enter into the correctness of what we’re doing. It’s always legal to retain an object, and it’s always legal to release an object we retained. Why are the solutions the same? Because in A, there’s an implicit retain associated with storing a strong reference, and that’s what makes it strong. The reference itself (the 4- or 8-byte pointer) is irrelevant to memory management. In A, it’s merely overhead. In B, we keep the retain, and eliminate the overhead. So, as Graham says, it’s hard to see where the tacit resistance to B comes from. No one seems to be unhappy about A, apart from the waste of memory, and B *is* A without the waste of memory. [Bonus sermon: Of course, if GC were being used, it’s the 4- or 8-byte pointer itself that makes the reference strong. Or, more exactly, its the reachability of the pointer that makes the reference strong. Under GC, you’d either have to use solution A, or invent custom reference counting. Which brings us back to NSDiscardableContent. It was introduced with 10.6, which IIRC makes it pre-ARC, in an era when GC was trying to be dominant. In those terms, it doesn’t seem so weird that a new style of reference counting was introduced, since it didn’t really duplicate anything you could do in GC. I just don’t see it as providing extra value any more.] _______________________________________________ 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
