Memory Fragmentation

When building a large project in FlasCC, you may notice that your application cannot allocate new memory even when there is enough free memory on your computer. The same application may run successfully in a clean environment or when you use a stand-alone player. This issue with memory allocation is a result of fragmentation.

The following concepts set a background to the solution for the memory fragmentation issue.

1. All instances of Flash, running in the same browser, share a single process. This means that your app could be affected by other Flash instances running at the same time. An exception to this is the IE browser which provides several processes to alternately run Flash content.
2. For 64-bit processes, the virtual memory space is relatively very large--2^64B. The virtual memory space for 32-bit processes, however, is very limited. The default space for 32-bit processes is 2GB for applications on windows. Enabling the large address space flag on windows can stretch the available space to 4GB (some of it is reserved by the system, so you still can’t use the whole 4GB).
3. When creating a new object for AS3 applications, you need a memory fragment the same size as that of the object. FlasCC applications use domain memory as the C/C++ stack and heap. Domain memory is a single ByteArray which needs a block of consecutive memory. This means that when creating a C/C++ object in FlasCC, you have to save it in domain memory. For a large FlasCC project, the total memory usage can reach hundreds of MB, which means it needs a large block of consecutive memory.

Here’s an illustration of the memory allocation problem:

• Free Memory
• Memory Used by normal AS3 Objects
• Reserved Domain Memory, available for C/C++ Objects
• Domain Memory used by C/C++ Objects

1.At first, the Flash Player memory running in the browser may look like this:

2.When you run your FlasCC application, the memory allocation may look like:

3.Your FlasCC application may also create some AS3 Objects:

4.Your FlasCC application may then create new C/C++ objects, or release old C/C++ objects at run time. The memory allocation may change to:

5.If your application needs more memory for new objects than available in the reserved domain memory, FlasCC has to extend the domain memory. Unfortunately, there is no free memory that is contiguous with the domain memory, so FlasCC needs to copy the whole domain memory to a new location:

6.Now if you open other web sites with Flash content, in the same browser, the memory allocation changes to:

If your FlasCC application needs some more domain memory to create new C/C++ objects, memory cannot be allocated because there is no memory contiguous with the domain memory, nor is there a new large consecutive memory block for copying.

This problem is not so severe for a 64-bit Flash Player because the virtual process memory space is much larger than the physical memory. For a 32-bit Flash Player, IE provides several processes to run Flash instances alternately. The Firefox Flash Plugin enables the large address space flag, thus limiting the memory allocation problem. The impact of memory fragmentation is significant in some browsers (like Chrome) running 32-bit Flash plugins, resulting in applications failing to run. The Chromium database includes a bug to enable the large address space flag. This might help resolve the issue in future releases of Chrome. Meanwhile, you can work around this issue by pre-allocating enough domain memory for your FlasCC application:

This means that your application has enough domain memory for dynamic creation of C/C++ objects, and your run-time memory requirements will not extend the domain memory. AS3 objects created by your application or other Flash applications will also not affect your application.

Pre-allocate domain memory prior to C/C++ initialization. FlasCC uses Console.as as the entry of C/C++ initialization. Rewrite Console::init to optimize memory usage. See the following code snippet:

protected function init(e:Event):void
{
    var p:int=CModule.malloc(1024*1024*256);//pre-allocate a block domain memory, the size should be according to your project
    if (!p)
        throw(new Error("You have opened too many pages, close some of them or restart your browser!"));
    CModule.malloc(1);//take up the domain memory
    CModule.free(p);//release the pre-allocated memory so that it can be used for new C/C++ Object
    ...
}

Compile the rewritten Console.as to Console.abc and use the -symbol-abc option to compile your FlasCC project. For more information on compiling Console.abc, please refer to sample/04_Animation in the FlasCC SDK.