The memory usage of threads

In C and C++ programming, creating threads is not a very expensive operation. Threads not only leverage multiple CPU cores but they also share memory in the same process. For large game engines, several threads are created to process various computing tasks thus improving performance. Creating multiple threads in a large FlasCC project however, results in serious memory issues.

This article discusses the implementation of threads in FlasCC. A thread in FlasCC is not a thread in the truest sense. A FlasCC thread is not supported by the operating system like those of native applications. FlasCC can only access the public AS3 APIs provided by Flash Runtime. This means that you cannot really create threads in FlasCC because Flash Runtime doesn’t provide any native threading APIs. Flash 11.4 introduces the Worker feature while Flash 11.5 introduces the Shareable ByteArray feature on which FlasCC threading is based. The following illustrates the two new FlasCC features:

Every Flascc thread is indeed a single Flash worker. Flascc hides the process of worker creation, providing you the Unix-like pthread APIs. If you use Scout to investigate a Flascc application which uses multiple threads, you may see multiple Flash instances. Here is a snapshot from 09_Pthreads in the FlasCC SDK:

There are three main types of memory that a FlasCC thread uses:
1.Code Memory: This contains all the definitions of functions and classes. It is executed by a Flash Worker. It is not shareable across different workers.
2.Flash Objects Memory (Heap Memory): This is not extensively used by FlasCC but a few elements like function maps, thread identifiers among others need to be stored here. It is not shareable across different workers.
3.Domain memory: This is specifically designed for FlasCC. FlasCC uses it as a C/C++ stack and heap which makes read and write operation much faster. The domain memory is shareable which means that the threads in FlasCC can share variables.

You can use Scout to investigate the usage of each memory type. Here is a snapshot of another large project (the sample/09_Pthreads in the SDK is not large enough):

In this case, when you create a new thread, the Domain Memory is shareable. Hence, no extra domain memory is needed for the new thread. However, because the Flash Object Memory and Code Memory are not shareable, any new thread will need a copy of them. Note the memory usage of the Flash Object Memory and Code Memory. Any thread that you create consumes around 140MB of memory even if it does not perform any operation. If your application has too many threads, there are high chances of triggering a memory fragmentation issue.

In summary, creating a thread in FlasCC isn’t as cheap an operation as it is in native code. The native threading mechanism is not provided for security reasons—FlasCC does not call any OS APIs out of Flash player. You should optimize the usage of threads and create only those that are absolutely necessary. Some large scale FlasCC projects are known to run at optimum performance levels on not more than three threads.