On 12/6/16, 10:46 AM, "Kyle McKnight" <[email protected]> wrote:
>Does that rule apply with reusable item renderer's though or do you need >to >be more careful with them? I can't immediately think of any reason the rule wouldn't apply to reusable item renderers. Basically, the GC code will mark every object it can traverse to from the "GC Roots" and then sweep what isn't marked. A reusable renderer might be on the list of recyclable renderers and while it is, it shouldn't get GC'd. If the renderer is referencing other things, those things won't get GC'd and there have been bugs like that. I believe the DG now sets the data to null when putting a renderer on the recyclable list, since that could pin data objects in memory if it didn't. I also believe there is a way to get the DG to flush the recyclable list. It is true that the more references to other objects you have, the greater chance there is that you'll hit a bug in the GC where it might see some data value as a reference pointer and then not GC something. But IMO, unless your app needs to run forever, the overhead of finding the right time to release all references isn't worth it. -Alex > > >Kyle McKnight >Senior UI Engineer - Accesso >602.515.1444 (M) > >On Tue, Dec 6, 2016 at 1:40 PM, Alex Harui <[email protected]> wrote: > >> >> >> On 12/6/16, 10:21 AM, "bilbosax" <[email protected]> wrote: >> >> >This sounds like a promising solution, but I have always been a little >> >weary >> >about adding listeners to a renderer. Do they get immediately removed >> >when >> >a renderer is recycled, or do you have to handle removing them someway? >> >> Listeners to yourself or your children do not affect whether the object >> can be garbage collected. Listeners to parents or to external objects >>can. >> >> -Alex >> >>
