Comments on: Garbage Collection with Flex and Adobe Air

By: lwz7512

lwz7512 — Sun, 24 Jan 2010 15:33:12 +0000

great post,I’ve translate to chinese:
http://www.riameeting.com/node/587

By: Cesare

Cesare — Thu, 21 Jan 2010 18:57:42 +0000

The cache I use is a way to ensure that each renderer has only, at most, 2 references: one in the display tree and one in the cache itself. I got to this solution by experimentation and I solved many of the issues I had when dealing with renderers.

By: Rob McKeown

Rob McKeown — Thu, 21 Jan 2010 18:48:25 +0000

So when removing from the cache, how do you ensure that its memory gets freed? It doesn’t look like it is doing anything special with the renderers other than store them in a collection. Would cache.removeItemAt(n) free the memory allocated to the renderer and position n? I guess I don’t understand why removing an item from the cache would behave any differently than removing from the display list (assuming there are no other references to the renderer).

By: Cesare

Cesare — Thu, 21 Jan 2010 18:05:17 +0000

Beware, removeChild just removes a renderer from the display tree, as explained in the post. This does not ensure it is removed from memory. Before calling removeChild you can call MyRendererCache.setRenderer(…) to give it back and there you can check whether your cache is too big or not: if yes, you can remove some renderer also from the cache.

By: Rob McKeown

Rob McKeown — Thu, 21 Jan 2010 17:01:17 +0000

Understood… the way I have implemented this in Klok is that the container manages the renderers by doing basically what your cache does so that when the data provider changes, no new renderers are created unless there weren’t enough. However, if the new data provider has less items, then I remove the child renderers using removeChild. I would like to ensure some way of efficiently freeing their memory so that I don’t have the problem you describe.

By: Cesare

Cesare — Thu, 21 Jan 2010 16:49:00 +0000

@Rob The cache prevents them from being collected, but is also establishes a limit: if you loaded 20-30-10 items your cache length will be 30. With no cache you might have, in the worst case, 60 renderers.
If you have an application with high variability (alternate loading of many and few data) it is better to have a policy in the setter, as explained above.
In the “normal case” it depends on the implementation: e.g. if you use a Repeater component you can have a look at the generated code, if you code it your own you are responsible for that. My solution is just a way to have a controllable “centralized” mechanism to generate/delete renderers, so if there are issues about memory I know where to look in the code.

By: Cesare

Cesare — Thu, 21 Jan 2010 16:32:52 +0000

@Rob Thanks for your question. This depends on the policy of the cache setter. Instead of just adding the “used” renderer to the cache you can do a check on the length of the cache itself and, if greater than a given threshold, you can avoid to add it. To me, the only way to find the “best” value of the threshold is by experimentation, for it depends on many factors: the application, the number/frequency of queries, the number of returned results, the complexity of the renderer…

By: Rob McKeown

Rob McKeown — Thu, 21 Jan 2010 16:31:11 +0000

Now that I think of it, wouldn’t the fact that you are keeping a reference to extra renderers in your cache prevent them from ever being garbage collected? Where in the normal case they do eventually get collected?

By: Rob McKeown

Rob McKeown — Thu, 21 Jan 2010 16:17:45 +0000

In your caching example, the cache grows but never shrinks. In the case of a screen where you are loading data from the server, the cache may spike to display the contents of the longest collection. However, if you then load a set of data that is 10% of the previous one, your cache would still have far too many renderers cached. Is there a preferred technique for destroying unneeded renderers in a way that frees their memory?

By: Cesare

Cesare — Thu, 21 Jan 2010 16:04:38 +0000

@Corey Thanks for stopping by. I will have a look at the new 10.1 player and see if it optimizes memory usage. When will it be released as final?