Re: GC memory leak - what is it?
On Jan 4, 2010, at 11:50 AM, jonat...@mugginsoft.com wrote: A recent post mentioned the concept of GC memory leakage. How is is this defined? Is it merely a failure to nil out a rooted reference? man heap(1) makes reference to over-rooted objects. Are these merely objects with more than one root reference or is something else afoot? Under GC, a memory leak will fall into one of two categories: (1) An object was CFRetain'd, but never CFRelease'd. This is exactly like over-retaining an object in non-GC . Note that, in general, if you are using CFRetain under GC, it is only to work around a limitation somewhere or because of a design flaw. If you need to use CFRetain to work around something, please file a bug! (2) A hard reference to an object that isn't cleaned up. For example, many applications have a cache somewhere, typically key/value pairs. I have seen a number of these where, under non-GC, the cache never retained the values and was never pruned. Because the values were never retained, the values in the cache were released and deallocated, leaving behind a dangling value with a key that would no longer ever be accessed. In the move to GC, this created a leak in that the cache would often default to a strong reference. Lesson; prune your caches! It isn't so much thinking of it as a reference that needs to be nil'd out as much as it is a need to properly disconnect a subgraph of objects from the live object graph in an application such that the subgraph is collected. That is, nil'ing out references is a fix for a symptom where the overarching problem is one of properly managing the connectivity of the object graph within the application. b.bum ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: GC memory leak - what is it?
jonat...@mugginsoft.com wrote: A recent post mentioned the concept of GC memory leakage. How is is this defined? Is it merely a failure to nil out a rooted reference? Yes. If you hold a reference to memory you don't need anymore, you have a leak. I've gotten into huge flamewars over this, but I'm convinced of its truth. Consider a Java Document Object Model tree. Every node holds a reference to its parent and all of its children. If you hold a reference to any node in the tree, you prevent the entire tree from being collected. If you can't be sure that some other code will nil out your references, then nil them out yourself. Rippit the Ogg Frog rip...@oggfrog.com http://www.oggfrog.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: GC memory leak - what is it?
On 4 Jan 2010, at 20:39, Bill Bumgarner wrote: It isn't so much thinking of it as a reference that needs to be nil'd out as much as it is a need to properly disconnect a subgraph of objects from the live object graph in an application such that the subgraph is collected. That is, nil'ing out references is a fix for a symptom where the overarching problem is one of properly managing the connectivity of the object graph within the application. b.bum Thanks for the clarification. I am using the ObjectGraph tool in Instruments. The table view for this tool has a Root column. Presumably a item marked as Root is one of : global variables, stack variables, and objects with external references Browsing through User-defined Root objects I can see in the Extended Detail view that some of my objects have multiple stack roots. How can a multiple stack root occur? Is this just saying that the same object is referenced by multiple stack allocated pointers at the time that the sample was taken? Presumably a stack root cannot be the source of any persistent leak as once the frame is gone so is the root. Sorry if this is dumb question. I am struggling to comprehend just what the ObjectGraph tool is telling me. Docs seem MIA for this tool (or maybe it's me that's MIA). Most of my rooted objects are statically allocated singletons. ObjectGraph correctly identifies them as single roots. Thanks again Jonathan Mitchell Developer mugginsoft.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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: GC memory leak - what is it?
On Mon, January 4, 2010 12:39:22 PM Bill Bumgarner b...@mac.com wrote: It isn't so much thinking of it as a reference that needs to be nil'd out as much as it is a need to properly disconnect a subgraph of objects from the live object graph in an application such that the subgraph is collected. That is, nil'ing out references is a fix for a symptom where the overarching problem is one of properly managing the connectivity of the object graph within the application. Does anybody know how the collector actually works? I've read the docs a dozen times but something about the description makes me think it doesn't exactly happen the way it's described. According to the docs, the collector scans all of your objects to determine what needs to be deallocated. But in performing this scan, how does it know which bits in your object are pointers to other objects and which bits are just data? I think that an understanding of what actually happens behind the scenes would clear up a LOT of the common questions we see here about GC. Soong ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: GC memory leak - what is it?
On Jan 4, 2010, at 2:27 PM, Oftenwrong Soong wrote: According to the docs, the collector scans all of your objects to determine what needs to be deallocated. But in performing this scan, how does it know which bits in your object are pointers to other objects and which bits are just data? The Objective-C compiler has always generated extended type information for classes, so you can not only tell what the offset of an instance variable is at runtime, but also what its type is. When building GC-supported or GC-required, the compiler additionally provides a layout bitmap that gives the collector a faster way to know what offsets should be considered to hold strong and weak references. See class_setIvarLayout and class_setWeakIvarLayout in the Objective-C Runtime Reference; anyone constructing classes “by hand” (e.g. using objc_allocateClassPair) needs to use these if they want their classes to work under GC. — Chris ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: GC memory leak - what is it?
On Jan 4, 2010, at 1:39 PM, jonat...@mugginsoft.com wrote: How can a multiple stack root occur? Is this just saying that the same object is referenced by multiple stack allocated pointers at the time that the sample was taken? That is correct; the object may be referenced by multiple local variables [on the stack]. Note that since the stack is scanned conservatively, you may be seeing stale references -- references that have gone out of scope. Presumably a stack root cannot be the source of any persistent leak as once the frame is gone so is the root. One would like to believe that, but it isn't always the case. On AMD64, the ABI specifies that there is a red zone of 128 bytes allocated just below the current stack pointer that can be used as scratch space. Thus, the collector has to also scan the red zone conservatively. However, the red zone will often contain whatever local variables -- including arguments (which are an awful lot like local variables, really) -- that were written there when the current frame called a function somewhere, pushing a frame below. Hence the need for objc_clear_stack(). Among other things, it clears the red zone. (Don't let the details scare you -- as long as you are using the recommended run loop / grand central dispatch mechanisms for looping and waiting, clearing the stack is handled automatically. That is, very very few developers will ever run into a need to deal with this directly). Sorry if this is dumb question. I am struggling to comprehend just what the ObjectGraph tool is telling me. Docs seem MIA for this tool (or maybe it's me that's MIA). File a bug, please! Most of my rooted objects are statically allocated singletons. ObjectGraph correctly identifies them as single roots. Good. Note that you can also use gdb to perform the same analysis. In any GC'd program, 'info gc-roots addr' and 'info gc-referers addr' can be used to interrogate the connectivity of the object at addr. b.bum ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
