Re: Memory not being released in a timely manner
Re: Memory not being released in a timely manner
- Subject: Re: Memory not being released in a timely manner
- From: Fritz Anderson <email@hidden>
- Date: Fri, 07 Jun 2013 09:46:03 -0500
On 7 Jun 2013, at 6:05 AM, Jonathan Taylor <email@hidden> wrote:
> [Greg Parker:]
>> "The Allocations instrument should report objects with pending autoreleases as ordinary live objects"
>
> Do you happen to know if that's true of Allocations on 10.6? Is that definitely true for objects that have actually passed out of scope, and it would therefore be forbidden to re-retain them (if you know what I mean), but which haven't actually been freed "behind the scenes"?
Greg Parker's lightest word would annihilate even my deepest thoughts, but this is my no-inside-information understanding of the semantics of the autorelease pool:
It's just a broker with no insight into the state of the objects it holds. It does a retain when an object is presented, counts the retains it does, and does N releases when the pool is drained. Nothing special, and no way to decide whether all of the ownership count relates to what may be a stack of autorelease pools.
There are optimizations — ARC includes a lot of them — but people have relied on those semantics for decades, and there's not much scope to change them. It has to act-as-if.
If you already can pick out the object you're interested in in the Allocations history, and you turn retain tracking on, you can study the retain count and see how many times the object has been autoreleased. But Instruments has no way of flagging whether a retain pattern is other than what you expect/intend.
The out-of-scope compile-time condition you suggest would be very hard to detect reliably. Clang may be insightful enough that it could instrument the object code to give the Allocations instrument clues, but that would be the next OS at the earliest, and doesn't help you on Snow Leopard.
I have no clue about your root problem, which is bizarre according to what you've told us. My approach to such things is to blunder around until something suggests itself. It smells like you're doing a lot of processing with temporary objects, in a loop, without bracketing the loop body in @autoreleasepool{}, but I remember you saying you're not.
[I remember vaguely that CG operates its own heap for image buffers, which is what your error message complains about. I dealt with it a long time ago, and I may be misremembering. What does the VM Tracker instrument say?]
— F
--
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279
_______________________________________________
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