It's on incoming now, but reaching master depends on the bots being fixed, and they have been broken for a while now due to various issues - not sure when that will get resolved.
On Sun, Sep 13, 2015 at 10:58 PM, Sergey Solozhentsev < [email protected]> wrote: > 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. > -- 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.
