Sorry for the confusion here, those are actually two separate scripts. split_asm.py is older, and does something similar but different. I removed it now since it hasn't been used by anything for a while. The proper tool is separate_asm.py (added in 1.34.6).
On Fri, Sep 4, 2015 at 12:01 AM, Sergey Solozhentsev < [email protected]> wrote: > 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. > -- 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.
