Hi Warren, I have no idea if this is related to your problem, but we ran into some memory problems in our engine.
Allocating a typed array requires an available, contiguous block of address space of that size. In a 64-bit process, that's no problem at all. There is tons of address space available. On 32-bit browsers on 64-bit windows (assuming the browser was compiled with /LARGEADDRESSAWARE), this isn't that much of a problem, since each process gets 4 GB of address space. On 32-bit browsers on 32-bit windows, each process has only 2 GB of address space available. Thus, it's quite likely that a browser process, especially one that's been in use for some time, won't have many large contiguous blocks of memory available. Our internal tests showed that you can't count on 256 MB in Chrome on 32-bit Windows because Chrome randomizes base address for security. Chrome is in the process of disabling randomized allocation on platforms with limited address space, such as 32-bit Windows: https://code.google.com/p/chromium/issues/detail?id=394591 We have yet to gather statistics from our customer base, but we've been trying to keep our maximum ArrayBuffer size below about 100 MiB. On Thu, Dec 18, 2014 at 4:00 AM, Warren Seine <[email protected]> wrote: > > Hi guys, > > I'm trying to investigate a leak in our engine and was wondering why the > memory limit would behave differently on mobile and desktop browsers. All > mobile browsers crash with a TOTAL_MEMORY exception while desktop browsers > don't. I'm especially trying to fix this on iPad, but that's also the case > on Android. > > I thought I understood asm.js and made the following assumptions: > > 1. Before starting the program, Emscripten with asm.js will allocate a > big array to simulate the RAM. > 2. The size of the memory array depends on TOTAL_MEMORY. > 3. Besides browser-specific optimizations, the allocated / used memory > by a program is deterministic. > 4. If TOTAL_MEMORY is too big for the actual device, the browser will > immediately crash. > > What I'm experiencing clearly shows that I'm wrong about assumptions #3 > and #4, so here's a few questions: > > - Do browsers perform some "virtual memory" allocation of the asm.js > array? Some trick that would make a 256 MB array not crash in Safari Mobile > until being actually filled with data. > - What would be a safe TOTAL_MEMORY value for mobile browsers? > - What's the best technique for memory profiling in JavaScript when > using asm.js? Can --profiling help profiling memory if the memory > array is preallocated? > - What's the role of the memory initialization file? What does it > contain on startup? > > > Thanks a lot, > Warren. > > -- > 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. > -- Chad Austin Technical Director, IMVU http://engineering.imvu.com <http://www.imvu.com/members/Chad/> http://chadaustin.me -- 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.
