3

We've got quite a massive codebase compiling and starting to run in FlasCC. When you just open the .swf, player's memory usage is ~300MB. It is more or less fine, since it seems like there's still around 300MB of dynamically-allocated memory available to the C++ code.

Problems start when we create threads. According to documentation, every thread copies the .swf in memory and runs in a sandbox. Does that mean that every pthread will eat up the same ~300MB of memory that were used by the player to open the .swf?

It seems so. I've done a simple test of spawning pthreads and dumping memory usage (what flash.system.System reports to us, as well as CModule.ram.length). Here's the log:

Starting 10 threads.
Memory usage: total=288MB private=335MB free=2MB CModule=33MB
Thread 0 started.
Memory usage: total=683MB private=732MB free=1MB CModule=36MB
Thread 1 started.
Memory usage: total=1071MB private=1121MB free=1MB CModule=37MB
Thread 2 started.
Memory usage: total=1459MB private=1510MB free=1MB CModule=38MB

At that point plash_player_debugger has exited (crashed) without any error messages.

This basically means no threading for us. After starting 2 pthreads, there's only ~50MB of memory available to the C++ code left.

Adobe Scout gives a bit deeper breakdown of memory usage. Here's what it reports when an .swf is running with 2 background threads: (a picture from the same question on Adobe forums)

The "Other" block has inflated from 11 to 800 MB after spawning these 2 idle pthreads. The memory was going into "Other Players" and "Uncategorized".

So the main question is: how to workaround this? Maybe there's a way to make AS3 workers consume less memory?

ilookha
  • 106
  • 4

1 Answers1

1

If you consider the AS3 workers API, you have the ability to pass any SWF file to be executed.

Most examples (in AS3) suggest passing the current SWF bytes and then use something like Worker.current.isPrimordial to decide what to do.

So, while I don't think you can avoid the fact you will have as many player instances as threads, a far better approach is to make the worker SWF a separate module that does not reclaim as much memory as the main SWF.

For your case specifically, I realize this is probably very difficult since you rely on Adobe's implementation of pthread with workers, which is obviously just passes in the main SWF file as the worker. In addition, moving an existing C/C++ codebase using threads to AS3 workers is far from being trivial.

Antoine Lassauzay
  • 1,557
  • 11
  • 12
  • Yep, I thought about spawning workers from a different module. That means we should decouple and isolate all C++ code which is run by background threads in a separate FlasCC target. Which is kind of good from code modularity point of view, but presents a huge amount of work if you need to do it on a large C++ codebase written under different assumptions. So I was hoping that there's some magical trick to avoid rewriting everything. – ilookha Mar 13 '13 at 05:47