when I changed order of loading files I got Uncaught TypeError: Module._malloc is not a function processPackageData @ asm.js:1 runWithFS @ asm.js:1 callRuntimeCallbacks @ asm.js:1 preRun @ asm.js:1 run @ asm.js:4 runCaller @ asm.js:4 removeRunDependency @ asm.js:1 (anonymous function) @ asm.js:1 xhr_onload @ asm.js:1
On Fri, Sep 4, 2015 at 10:06 AM, Sergey Solozhentsev < [email protected]> wrote: > the second and third point was my fault. I didn't remove loading whole > script. > But now I got other error > Uncaught ReferenceError: asm is not defined > from asm.js > > On Fri, Sep 4, 2015 at 10: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.
