Memory Management for Flex and AIR Developers

Memory Management for Flex and AIR Developers

Presented by Jun Heider, ACIRealEyes Media

[email protected]

Memory Management for Flex Developers

About me• Jun Heider

– Adobe Certified Flex developer and instructor

– I work for RealEyes Media in sunny Denver, CO http://www.realeyesmedia.com

– I have worked on Flex/AIR applications and consulting for Fortune 500 financial corporations, government, and many other private sector firms such as Chase Manhattan, US Navy, and GLOBE/UCAR

– Blog http://office.realeyesmedia.com/blogs/jun

http://www.realeyesmedia.com/

http://office.realeyesmedia.com/blogs/jun


Synopsis• The emergence of Flex-based applications in the enterprise

and the push of AIR-based applications to the desktop has prompted an awakening of Flex/AIR developers in the area of memory management.

• Due to the lazy nature of the Flash Player 9 garbage collectionroutines, memory consumption left unchecked can quickly drive the high-performance required in your applications downhill.

• However, with the proper approach and methodical systematic development processes, memory management techniquescan be utilized to keep memory consumption to a minimum.


Why do we care about memory management?

• We want our applications to run fast (Stare too long at a busy cursor…your eyes will go bad and your temper will rise)

• We want our applications to be stable (No memory leaks or browser crashes)

• We want our applications to treat their host OS and neighboring processes with respect (Save some system memory for the other applications…jeez)

• We want our code to hold up to industry standards and best practices (Well, most of us do…)



• There are many types of memory-intensive situations that require attention:– Large datasets/assets (Catalog management application, Photo

gallery application)– Extended runtime requirements (8 hours a day for example)– Large forms with several views and many controls (Home loan

application) – Lesser spec’d hardware (RAM-constrained)



• DEMONSTRATION– Two applications with almost the same code base

– The difference is one application uses memory management techniques and best practices while the other does not


Memory management, how shall we proceed?

1. Background information: Before we start, we need to know how Flash Player 9 handles memory management

2. Best practices: When we code, we need to help the Flash Player figure out what needs to be managed

3. Tips and tools: When we debug and refactor, we need to know how to monitor and diagnose memory management issues


Background information - disclaimer• I am not an engineer on Adobe’s Flash Player team

• I have collected the background information from multiple sources several of them being Adobe engineers with access to developers on the Flash Player team

• Being that the sources agree with each other and I have not seen any indication otherwise I have a good feeling that this information is accurate

• Based on the background information and my own debugging and code development I have a good feeling that this information is accurate


Background information - How does the Flash Player manage memory?

• The Flash Player has a specific process when requesting additional memory from the system (allocation)

• The Flash Player uses a garbage collection model when releasing memory back to the system (deallocation)

• There are pros and cons to each of the above


Background information – memory allocation

• When memory is needed from the system Flash Player will request a large chunk of memory from the OS rather than requesting smaller chunks more frequently

• Flash Player breaks these large chunks into pools of smaller chunks and then hands them out as needed

• When more memory is needed Flash Player will maybe run garbage collection, and if necessary request another large chunk from the OS which it will then break into another pool of smaller chunks


Background Information – memory allocation

• DEMONSTRATION– The following demonstration illustrates the way in which Flash

Player normally allocates memory– Caveat: This does not hold true for larger data objects such as

bitmaps which require a large chunk of non-pooled memory

Demonstration (Flash Player Allocation animation)


Operating System

Flash PlayerA request is made for 256 bytes

Greedily, Flash Player requests more memory than it needs – 1024 bytes* -- to minimize calls to the OS

*Actual numbers my vary

Memory request is approved

256 Bytes

256 Bytes

256 Bytes

256 Bytes

Memory allocated


Background information – memory allocation (PROS and CONS)

• PROS– Performance: Rather than making many requests to the system for small

chunks of memory Flash Player makes more infrequent requests for large chunks of memory saving processor cycles and the response time of your application

• CONS– Greedy allocation: When Flash Player makes a request to the system for

memory it will request large chunks of a pre-determined size rather than small chunks sized for immediate need

– Memory footprint: With many large chunks of memory with little pieces of unused memory, over time the Flash Player will never release all unused memory back to the system


Background information – memory deallocation

• When new memory is requested, Flash Player may run garbage collection:

– The garbage collection process will use the following algorithms to find unused memory:

• Deferred reference counting• Mark and sweep

– If unused memory is found then garbage collection may try to consolidate used portions to try and deallocate some of the large chunks back to the system



• DEMONSTRATION– This demonstration illustrates the way in which Flash Player

garbage collector works

Demonstration (Garbage Collection Animation)


256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

256 Bytes

Allocated

Free – not GC’d

Garbage Collection Run 1

Garbage Collection Run 2

Free to be released back to the OS

Free

Request for 256 Bytes

Memory almost out, run GC!

Request for 256 Bytes

Release of 256 Bytes



• The Flash Player garbage collection routine deferred reference counting works by counting STRONG references** against a particular object

• If the object has a reference count of 0 then the memory used to store it will become a candidate for reuse by the player or release back to the system

• This algorithm does not count weakly referenced event listeners** or weak object references**

**We’ll discuss what these are in a little bit



• The Flash Player garbage collection routine mark and sweep works by starting at the root and working it’s way down the hierarchy of memory objects

• The memory used to store objects NOT reachable via the parent-child hierarchy will be eligible for reclamation by the player or release back to the system



• DEMONSTRATION– This demonstration illustrates the way in which Flash Player

deallocates memory using deferred reference counting and mark and sweep

– http://www.gskinner.com/blog/archives/2006/09/garbage_collect.html

http://www.gskinner.com/blog/archives/2006/09/garbage_collect.html

http://www.gskinner.com/blog/archives/2006/09/garbage_collect.html


Background information – memory deallocation (PROS and CONS)

• PROS– Performance: Since it doesn’t run all the time and every time, it saves on

processor cycles and response time of your application

• CONS– Indeterminate: garbage collection only runs when more memory is needed

but not every time

– Iterative: It may take a few passes for garbage collection to finish consolidating pools or release memory back to the system

– Involuntary: There is no supported/recommended way for a developer to force a garbage collection run


Best practices – how do we help with memory management?

• As developers, we work with the knowledge of how the Flash Player allocates and deallocates memory

• This knowledge is used to determine memory management best practices when coding


Best practices – thoughts on allocation

• Thought: – Once a large chunk of memory is allocated to the Flash Player,

there is a chance that the chunk will never be released back to the system

• Observations:– The key is to only use memory when necessary

– Deferred loading and instantiation assist with frugal memory consumption


Best practices – allocation concerns• Based on Flash Player memory allocation observations

we need to keep the following in mind while coding:– Datasets retrieved from services

– Assets loaded in at runtime

– Components


Best practices – allocation concerns• Dataset retrieved from services:

– Start with estimating the number of records a user will need right off the bat, this will be the initial data pull

– You can retrieve the rest of the data using paging

– Use <mx:DataService/> and FDS Data Management Service destinations with the paging feature enabled


Best practices – allocation concerns• Assets loaded in at runtime:

– Assets include: images, sound, video, and other SWFs

– The more assets you load, the more memory required: use discretion when loading assets in at runtime

– Either load in assets one-by-one or try to predict the number of assets that will actually be used


Best practices – allocation concerns• Components

– Make use of deferred instantiation, and manual creation methods

– Be very wary of creationPolicy="all"

– Also, when using the combo of removeChild() and addChild() on a component, see if there is a way to reuse the component vs. adding and removing brand new instances


Best practices – thoughts on deallocation

• Thoughts: – We can never be sure when garbage collection will run or what it

will handle during each run

– Based on the way garbage collection works, we can never be sure when our objects will be garbage collected

• Observations:– The key is to do everything in our power to remove references as

soon as they’re no longer needed


Best practices – deallocation concerns

• Based on Flash Player memory deallocation observations we need to keep the following in mind while coding:– Object references (namely complex objects)– Event listeners– Service connections– Modules– Assets



• Object references (namely complex objects)– Be wary of complex objects such as arrays, dictionaries, and large

developer-defined objects

– There is no built-in way to weakly reference another object, so remove references when you’re done with them



• Event listeners– It is good practice to try and use weakly referenced event listeners

whenever possible

// The last argument is useWeakReference:Boolean // which defaults to FALSEmyChild.addEventListener(MouseEvent.CLICK,onClick,false,0,true);

– If you add a strongly referenced listener try to remove the listener when you are done with it

myComponent.removeEventListener(MouseEvent.CLICK,onClick,false);



• Service connections– In other programming languages its best practice to close a file when you’re

done writing to it, in a similar way it is good to close service connections when you’re not using them any more:

• DataService: myDataService.disconnect();

• RemoteObject: myRemoteObject.disconnect();

• WebService: myWebService.disconnect();

• HTTPService: myHTTPService.disconnect();

• Socket: mySocket.close();

• NetConnection: myNetConnection.close();



• Modules– Don’t unnecessarily load or unload modules

– If you need to unload a module you will need to make sure to remove all references pointing into the module

– Regarding references: event listeners are backward! In other words if a module adds a listener to an event dispatched by it’s parent, the parent application references the module!



• Assets– Assets include: images, sound, video, and other SWFs

– Make sure to remove references to assets when they’re done being used by setting the references to null


Best practices – what about AIR?• The AIR runtime is based on Flash Player 9

• If you develop AIR apps with ActionScript 3 and MXML, the things we learn about Flex also apply to AIR…in other words, for the most part we’re addressing both platforms at the same time! ☺


Best practices – what about AIR?• AIR has access to NativeWindow while Flex does not

• After instantiating a NativeWindow you must issue a close() before it can become a candidate for garbage collection

• If you want the DisplayObject instances in your NativeWindow to become eligible for garbage collection, remove external references to them BEFORE issuing a close()! Reason being most properties and methods of a NativeWindow are no longer available after running close()


Best practices – what about AIR?• AIR has access to FileStream while Flex does not

• Be wary of opening a FileStream object in asynchronous mode: pending operations and event handlers listening for them to finish can prevent the FileStream object from being garbage collected


Best practices – give me examples!• DEMONSTRATION

– During this demonstration, various best practices will be shown and contrasted with their non-optimized counterparts


Tips and tools – what is available to help us with memory management?

• Some tips on debugging and refactoring would be nice

• It would be nice to have some utility classes or interfaces to assist us with facilitating memory management in our applications

• We need some tools to assist with monitoring and debugging our applications:– What kind of memory footprint does our application have?– Are there any memory leaks?– What happens to memory management if I make a slight change to

the code?


Tips and tools – pay attention during debugging and refactoring

• During the testing or maintenance phase, keep an eye on memory consumption and pay attention to what’s happening in the application when utilization spikes.

• Try not to change too much code at once before re-testing to see if modifications have made a positive impact

• Make sure that you are keeping revisions – preferably with developer notes – in case you need to revert or re-test!


Tips and tools – some times memory can be consumed by the weirdest things

• Memory can be consumed by:– Mouse movement– Modal pop-ups– Service polling– Scrolling within components

• When debugging, keep the above in mind, and don’t get too concerned with slight variances in memory allocation statistics (In other words, look at memory allocation at a higher level)

• Also, based on the above, the way in which a user interacts with an application will skew the results between debugging iterations


Tips and tools – when debugging, forget the user

• Use non-interactive repeatable sequences when debugging.

• If it’s available to you, use the Flex automation framework and QTP so that multiple functional test runs through an app will be identical


Tips and tools – utility classes• It would be nice to have utility classes or interfaces to:

– Know how much memory is being consumed– Allow us to log memory consumption for later analysis – Allow us to create weak object references– Help us with the cleanup process when objects are no longer

needed


Tips and tools – utility classes• DEMONSTRATION

– During this demonstration utility classes/interfaces that assist with memory management practices will be shown


Tips and tools – help me debug…• Various tools and methods to debug memory consumption:

– Manual debugging: • System.totalMemory• Timer• trace()

– Flex Builder 3 Profiler• Currently in Beta http://labs.adobe.com/technologies/flex/• Really granular• Integrated into Flex Builder

– REDbug• Currently in Beta http://www.realeyesmedia.com/redbug/• Easy to compare multiple test runs side by side• Load/Save results to/from file


Tips and tools – help me debug• DEMONSTRATION

– During this demonstration the various debugging tools will be used to debug sample code


In summary• Flash Player 9 memory management is an involuntary system that has been

architected for player performance and not necessarily 100% optimal memory utilization

• Utilizing best practices, specialized utility classes, and specialized interfaces during code development optimizes how your code interacts with Flash Player memory management

• Debugging your application using available tools allows you to profile and optimize memory management in your application


Memory management – who/what else can we learn from?

• Acknowledgements: Grant Skinner, Alex Harui, and Kyle Quevillon

• Resource Links:

– Grant Skinner• http://www.adobe.com/devnet/flashplayer/articles/resource_management.html• http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html• http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html• http://www.gskinner.com/blog/archives/2006/07/as3_resource_ma_1.html• http://www.gskinner.com/blog/archives/2006/08/as3_resource_ma_2.html• http://gskinner.com/talks/resource-management/• http://www.gskinner.com/blog/archives/2006/06/understanding_t.html• http://www.gskinner.com/blog/archives/2006/07/as3_weakly_refe.html• http://www.gskinner.com/blog/archives/2006/07/as3_dictionary.html• Just call him Mr. GC!

http://www.adobe.com/devnet/flashplayer/articles/resource_management.html

http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html

http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html

http://www.gskinner.com/blog/archives/2006/07/as3_resource_ma_1.html

http://www.gskinner.com/blog/archives/2006/08/as3_resource_ma_2.html

http://gskinner.com/talks/resource-management/

http://www.gskinner.com/blog/archives/2006/06/understanding_t.html

http://www.gskinner.com/blog/archives/2006/07/as3_weakly_refe.html

http://www.gskinner.com/blog/archives/2006/07/as3_dictionary.html


Memory management – who/what else can we learn from? (continued)

– Alex Harui• http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memor

y.html• Numerous well-written posts on Flexcoders!

– Kyle Quevillon • http://blog.739saintlouis.com/2007/03/28/flash-player-memory-

management-and-garbage-collection-redux/• Awesome Adobe Flex support individual!

http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memory.html

http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memory.html

http://blog.739saintlouis.com/2007/03/28/flash-player-memory-management-and-garbage-collection-redux/

http://blog.739saintlouis.com/2007/03/28/flash-player-memory-management-and-garbage-collection-redux/

Memory Management for Flex and AIR Developers

Documents

utility classes

garbage collection

flash player

memory consumption

unused memory

large chunks

memory management

release back