The memory usage of threads

In common C/C++ programming principle, creating threads is a cheap thing. And threads do not only leverage multiple CPU cores, but also share the memory in the same process. For a large game engine, it usually creates several threads to process different computing tasks, which makes the performance much better. But in FlasCC, the situation is very different. If you create too many threads in a large FlasCC project, you will encounter serious memory issues.

Now let’s explain how the threading is implemented. A thread in FlasCC is not a real thread supported by OS like the native application. Remember that FlasCC can’t do anything AS3 can’t do. In other words, FlasCC can only access the public AS3 APIs provided by Flash Runtime. As you may know, Flash Runtime doesn’t provide any native threading API, so it’s not possible to create real threads in FlasCC. Fortunately, Flash 11.4 introduces Worker feature and Flash 11.5 introduces Shareable ByteArray feature. Thread in FlasCC is based on these two features actually. See this diagram:
Every Flascc thread is single Flash worker indeed. Flascc hides the process of worker creating, providing you the unix-like pthread APIs for easy use. If you use Scout to investigate a Flascc application which uses multiple threads, you can see multiple Flash instances. Here is a snapshot from 09_Pthreads in FlasCC SDK:
There are three main kinds of memory FlasCC thread uses.
1.Code Memory. It contains all the definitions of functions and classes. It is executed by Flash Worker. It’s not shareable across different workers.
2.Flash Objects Memory (Heap Memory). It is not used much by FlasCC, but a few necessary stuff (function map, thread identifier and so on) need to be stored here. It’s not shareable, too.
3.Domain memory. It is specifically designed for FlasCC. FlasCC uses it as C/C++ stack and heap in which read/write can be very fast. Domain memory is shareable. That’s why the threads in FlasCC can share variables.

We can use Scout to investigate the usage of each memory. Because the sample/09_Pthreads in SDK is not large enough, we select another larger project. Here is a snapshot:
In this case, when you create a new thread, the Domain Memory is shareable, hence no extra domain memory for the new thread, sounds very good. However, because the Flash Object Memory and Code Memory are not shareable, any new thread will need a copy of them. Notice the memory usage of them. Once you create a thread, even it does nothing, it still consumes around 140MB memory! If your application has too many threads, it will lead to much bigger memory usage situation, which is unacceptable as web content and easily triggers another memory fragmentation issue.

In summary, creating a thread in FlasCC isn’t a cheap operation as in native code. We don’t provide the native threading mechanism for some security reasons—FlasCC doesn’t call any OS API out of flashplayer. You should optimize the usage of threads and create threads that are only very necessary. There are cases we have seen in big scale FlasCC projects that reduces the number of threads (no more than 3 threads) runs with good performance.