On May 20, 2015, at 01:41 , Britt Durbrow <bdurb...@rattlesnakehillsoftworks.com> wrote: > > A memory pressure event occurs, and OPC decides to evict DMO1, but it doesn’t > immediately go away, because VC1 is holding on to it. > > VC2 comes along and wants to get at the object with UUID 12345 (in order to > execute [someObject stealAllTheAir], lets say). > Sooo… OPC loads the data for UUID 12345 from file storage, alloc’s a new > object (call it DMO2), sets it’s parameters (including assigning the UUID to > it), puts it in the in-RAM object pool, and returns the new object as being > the object for UUID12345.
Overnight, I was thinking how to politely explain to Graham and others that they were on the wrong track because they were inventing different approaches to *cache* management, but this thread was about *memory* management because you already had working cache management. Turns out they weren’t so much off track as you need a smack upside the head. [Er, wait, you’re a big dude with a beard, so perhaps kittens instead? You like kittens? I don’t want to get hurt.] What you said in the quote above is just plain wrong. Of course it doesn’t work. It doesn’t work because it’s an incorrect “implementation” of the memory management strategy we’ve been discussing. Here’s how it actually goes: “A memory pressure event occurs, and OPC decides to “evict” DMO1. It therefore releases its ownership of DMO1, nothing more**. DMO1 doesn’t go away, because VC1 is holding on to it. OPC still has a non-nil weak reference to DMO1. “At some point, the memory pressure event ends. OPC retakes ownership of DMO1 and any other surviving objects it released during the memory pressure event, by re-retaining it and them. “VC2 comes along and wants to get at the object with UUID 12345. Sooo… OPC sees that it has a reference to DMO1 and it returns that.” The end. No duplicate. Note that it doesn’t matter whether VC2 “comes along” before or after the memory pressure event ends [though there may be separate thread safety issues that require the memory pressure event to be atomic]. Note also that this is only case 1 of 3: Case 2. VC1 no longer has a reference to DMO1 at the time of the memory pressure event, and (as it happens) there is no other strong reference outside OPC. In this case, DMO1 dies during the memory pressure event. When VC2 comes along, the OPC weak reference is nil, and DMO2 is created. The end. No duplicate. Case 3. VC1 no longer has a reference to DMO1, and (as it happens) there is some other strong reference that you have no direct knowledge of. In this case DMO1 survives the memory pressure event, and when VC2 comes along it gets DMO1. The end. No duplicate. The three cases correspond to what I’ve been calling “referenced”, “unreferenced” and “inaccessible”. ** In practice there may be a little something more in the way of housekeeping. If you’re selectively releasing things from the cache, you might need to keep track of what you did, so that you re-retain the correct subset of OPC references later. If you don’t need to be selective, it’s easier because you just release everything in OPC at the start of the memory event, and re-retain everything in OPC [that still has a non-nil pointer in OPC] at the end. _______________________________________________ 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
