multithreading - How to workaround huge pthread memory cost in FlasCC? -

we've got quite massive codebase compiling , starting run in flascc. when open .swf, player's memory usage ~300mb. more or less fine, since seems there's still around 300mb of dynamically-allocated memory available c++ code.

problems start when create threads. according documentation, every thread copies .swf in memory , runs in sandbox. mean every pthread eat same ~300mb of memory used player open .swf?

it seems so. i've done simple test of spawning pthreads , dumping memory usage (what flash.system.system reports us, cmodule.ram.length). here's 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 point plash_player_debugger has exited (crashed) without error messages.

this means no threading us. after starting 2 pthreads, there's ~50mb of memory available c++ code left.

adobe scout gives bit deeper breakdown of memory usage. here's reports when .swf running 2 background threads: (a picture same question on adobe forums)

the "other" block has inflated 11 800 mb after spawning these 2 idle pthreads. memory going "other players" , "uncategorized".

so main question is: how workaround this? maybe there's way make as3 workers consume less memory?

if consider as3 workers api, have ability pass swf file executed.

most examples (in as3) suggest passing current swf bytes , use worker.current.isprimordial decide do.

so, while don't think can avoid fact have many player instances threads, far better approach make worker swf separate module not reclaim memory main swf.

for case specifically, realize difficult since rely on adobe's implementation of pthread workers, passes in main swf file worker. in addition, moving existing c/c++ codebase using threads as3 workers far being trivial.