Chrome Memory Issues

There are a bunch of known memory issues with running in Chrome,

• https://code.google.com/p/chromium/issues/detail?id=533648
• Possible workaround in https://github.com/kripken/emscripten/pull/3867
• https://code.google.com/p/chromium/issues/detail?id=533580
• https://code.google.com/p/chromium/issues/detail?id=417697
• https://code.google.com/p/v8/issues/detail?id=4392
• Improvements on Canary noticed on Unity forums
• https://code.google.com/p/chromium/issues/detail?id=394591

See also these general observations:

• http://blog.jellybtn.com/2015/08/16/porting-your-game-to-webgl-chapter-2/
• Unity WebGL forums
• http://forum.unity3d.com/threads/currently-supported-browsers.355687/
• http://forum.unity3d.com/threads/webgl-app-cause-chrome-crash-unity-5-2-0f3.353945/

Possible mitigations

• Make sure to fully optimize the build (-Oz, -O3 or -Os, for example); unoptimized or less-optimized builds take a lot more effort to run.
• Use the lowest possible TOTAL_MEMORY. In particular 32-bit Chrome seems to have a hard limit at 1GB, so if you can use just a little less like 950MB, that can work.
• Use --separate-asm, to split out compilation from starting to run the code, maximizing the chance that the browser can reclaim memory in between.
• If your project has a lot of file data, use LZ4 to compress it (-s LZ4=1 on emcc, and if you run the file packager separately, also --lz4 there). LZ4 decompresses so fast, there is hardly any slowdown to file access (sometimes it's actually faster).
• Reduce compilation memory by running some code in the Emterpreter (make sure to use EMTERPRETIFY_FILE as well). But, this makes the interpreted code much slower.
• Use dynamic linking to split the codebase into separate modules, which can reduce peak compilation memory usage compared to a single large asm.js file.
• Use SPLIT_MEMORY, to not require a single big typed array, and not require it all up front. But, this makes code run much slower.

Some of the possible mitigations decrease speed. You might want to make two builds, a normal one, and a slower-but-more-likely-to-work one, and if the first fails, you can detect that using a cookie and then suggest the user try the alternate build.

See also Chrome-Perf-Issues for performance problems on Chrome, which may interact with the problems here.