Re: ARC Retain Cycles
Re: ARC Retain Cycles
- Subject: Re: ARC Retain Cycles
- From: Dave <email@hidden>
- Date: Sun, 20 Apr 2014 21:22:55 +0100
Hi,
This App was an iOS application and previously it handled manual memory management - mostly using autorelease. I converted it by hand (didn’t use the ARC coversion process).
As for running the Static Analyser, I did run this and it showed no leaks, but some dead stores. I have just run it again, and the Static Analyzers now doesn’t seem to actually do anything? (I’m wondering if this might be a clue?). I do a “Clean”, then select Analyze. I says it’s Analyzing but stops quite quicking, I get some yello warnings but no Blue Warnings, and I *know* there are a couple of Dead-Stores in there!
Part of the code I suspect does things like this:
@property (nonatomic,retain) id propID;
@property (nonatomic,retain) UIImage propImage;
@property (nonatomic,retain) UIImage propDict;
if ([prop1 class] == [UIImage class])
self.propImage = self.pProp1;
if ([prop1 class] == [NSDictionary class])
self.propDict = self.pProp1;
This looked suspect when I saw it, but it seemed to work, so I left as is when converting to ARC.
Thanks for you help
Dave
On 20 Apr 2014, at 21:04, Quincey Morris <email@hidden> wrote:
> On Apr 20, 2014, at 11:58 , Cody Garvin <email@hidden> wrote:
>
>> Second, while using instruments use the “mark heap” tool.
>
>> Third, keep in mind that blocks keep strong references to self (especially callbacks).
>
> While these are important debugging steps, I’d suggest that this isn’t the place to start *in this case*.
>
> Assuming that this app is being converted from GC (Dave didn’t say so explicitly, but presumably conversion from manual RR likely wouldn’t introduce these kinds of memory issues), it’s probably better to spend more time looking at the source code *before* getting bogged down in debugging. There are two kinds of difficult problems that a GC-ARC conversion must contend with:
>
> 1. There are patterns of object usage that work fine in GC, but aren’t translatable directly into ARC. Specifically, when clusters of objects “go away automatically when they are no longer used” under GC, there may be no equivalent technique in ARC. (Of course, reference cycles are the underlying problematic mechanism, but I’m looking at a higher level.) In particular, under ARC it may be necessary to design the app so that it knows explicitly *when* such clusters are no longer used, and so can send explicit messages to cause the cluster to be deallocated.
>
> 2. Arbitrary object graphs that work fine in GC may be a tangle of cross-references in ARC. It may be best to redesign the data model so that the objects are strictly (or pretty strictly) hierarchical. That is, to change the data model from sibling relationships to parent-child relationships**. In other words, to change all the relationships to be “up” or “down”, and ensure that all the “up” relationships are weak***.
>
> Both of the above are most effectively done by examining and rearranging the source code directly, rather than trying to detect reference cycles in Instruments or the debugger, which limit you to a lower design level. A thorough source code review should remove *most* of the cycles, and then Instruments should help find the ones that are obscure at the source level.
>
>
> ** Of course, if the old data model is enshrined in (say) an archive saved in a document, then the app will still need to be able to recognize the old model.
>
> *** One resulting gotcha is that weak relationships are *not* KVO compliant, and that 10.9 will detect and complain about this, even in cases where 10.8 and earlier were silent. The original code was probably wrong in some way, too, but we often didn’t notice the problem because we tended to just grab a big hammer and smash things when closing windows etc. In 10.9, big hammers aren’t quite as smashy.
>
_______________________________________________
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