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.
