Hi I'm trying to use workaround but there are some issues 1) script is named split_asm.py and not separate_asm.py 2) After splitting I got 2 lines about memory allocation increasing TOTAL_MEMORY to 117440512 to be compliant with the asm.js spec (and given that TOTAL_STACK=5242880) i.e memory allocated twice 3) I got File exists uncaught error from asm.js
On Thu, Sep 3, 2015 at 3:36 AM, Alon Zakai <[email protected]> wrote: > There have been reports of problems with large compiled applications > running in Chrome, specifically, running out of memory during startup and > hitting a sad "aw, snap" page crash message, or a JS "out of memory" > exception thrown. More background: > > https://code.google.com/p/chromium/issues/detail?id=417697 > > This is obviously a very serious problem. If you've hit in in your > project, I would be interested to hear about your experience, and in > particular I'd like to know if the following workaround helps. The > workaround is described here: > > > http://kripken.github.io/emscripten-site/docs/optimizing/Optimizing-Code.html#avoid-memory-spikes-by-separating-out-asm-js > > and v8 bug is here: https://code.google.com/p/v8/issues/detail?id=4392 > > Basically, it looks like Chrome keeps around all the memory to compile as > the app starts up, and then the app allocates our typed array for memory, > filesystem, etc., and all together the browser can run out of memory. The > workaround splits out asm.js to a separate file and makes sure to spin the > event loop before running the app; this seems sufficient for Chrome to free > the no longer needed compiler memory, and avoid a high memory spike. (It's > not yet clear why this is a problem in Chrome but not other browsers, as > the v8 devs haven't responded yet in the bug. In any case, even if they fix > it soon, it's a few months to reach stable, so we will need a workaround > for now.) > > If you don't have crashes in Chrome, it can still be interesting to look > at memory usage over time (on linux, the System Monitor app is useful, when > set to maximum update speed). Without this workaround, on a large app you > might see rising memory, then a spike at the very end, after which memory > usage drops to something lower. With the workaround, memory usage should > still rise, but the spike shouldn't happen. I generally see a small dip > after compilation finishes, then it rises again as the app begins to run. > > If the workaround proves effective - this is what I am hoping to get > feedback on here - then perhaps we should apply it by default in emcc. This > would mean that emcc, when emitting HTML, would emit not 2 files but three: > the HTML, one asm.js file, and one file with all the rest of the JS (and > the HTML has the logic to load the asm.js first, etc.). (all of this with > possibly another file for the mem init) > > Adding another emitted file sounds like an annoyance, but arguments in > favor of it are: > > 1. Works around this issue in Chrome, letting large apps run properly in > that browser, assuming people's tests confirm what I see locally. > > 2. We are also going to eventually need such a split anyhow, when > WebAssembly gets closer: a WebAssembly module will definitely need to be in > a separate file, exactly parallel to the asm.js in a separate file in this > workaround. Doing this now could make the transition later more gradual. > > Thoughts? > > - Alon > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
