when will emcc with this option be published? On Wed, Sep 9, 2015 at 4:02 AM, Alon Zakai <[email protected]> wrote:
> To make this more convenient, emcc now has a --separate-asm option which > does everything for you. > > On Fri, Sep 4, 2015 at 10:28 AM, Alon Zakai <[email protected]> wrote: > >> 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. > -- 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.
