Re: Tracking the retain count
Haha. Awesome! I didn’t even know this existed… thanks for the tip :-) > On May 17, 2015, at 6:30 PM, Graham Cox wrote: > > >> On 18 May 2015, at 11:14 am, Jonathan Hull wrote: >> >> 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 > > > Yep. You could call it ‘NSDiscardableContent’ ;) > > —Graham > > > ___ 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
Re: Tracking the retain count
> On 18 May 2015, at 11:14 am, Jonathan Hull wrote: > > 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 Yep. You could call it ‘NSDiscardableContent’ ;) —Graham ___ 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
Re: Tracking the retain count
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 > 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
Re: Tracking the retain count
On May 17, 2015, at 18:10 , Quincey Morris wrote: > > 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. Er, I meant “put all the objects in both containers”. ___ 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
Re: Tracking the retain count
On May 17, 2015, at 17:47 , Britt Durbrow 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 (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
Tracking the retain count
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Fast enumeration question.
As others already noted the standard way is using the continue keyword.
However, if the conditional inside is scoped high enough, you can also just use
a guard if () {}
Putting everything inside the if block.
Then like any guard it's going to do nothing if the condition is false.
Most Objective-C collection types also have an enumerate objects block based
method with an index and a stopper for when you want something fast and that
offers a little more control than for-in and that is a bit more self
documenting in some ways.
Sent from my iPhone
> On 2015/05/15, at 1:09, Alex Zavatone wrote:
>
> I'm sure this will sound like the noobiest question ever, but with Fast
> Enumeration, if in an if statement within the loop, is there a way to stop
> loop execution and essentially do a "proceed to the next item in the list
> please"?
>
> Interested in something like BASIC's next repeat or something to that effect.
>
> In my scanning of the Apple docs, I didn't see that. Does break do that or
> simply break out of the loop all together?
>
> For example, if I'm counting from 1 to 10, hit 3, I want the loop to skip to
> 4 and keep going.
>
> Thanks much.
> ___
>
> 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/dangerwillrobinsondanger%40gmail.com
>
> This email sent to dangerwillrobinsondan...@gmail.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
