Hitting memory limit on mobile, not on desktop

[Warren Seine]

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.

[Alon Zakai]

On Thu, Dec 18, 2014 at 2:00 AM, Warren Seine <warren...@aerys.in> 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.

It should throw, but perhaps some browsers don't, and return null or something? Might add an assert right after "new ArrayBuffer" in src/preamble.js (2 places), to see if that catches anything (but it shouldn't).
 

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.

They might, sure, just like any allocation. I know that on linux malloc will eagerly return success, and when pages are actually used, problems might happen.

I would guess mobile browsers would be careful about this, but that's just a guess. Can file a bug to ask them.

 

• What would be a safe TOTAL_MEMORY value for mobile browsers?

Depends on the device. However, you should probably just use a very small TOTAL_MEMORY, and enable heap growth. That slows you down a little, but is more memory efficient. We are also making memory growth faster.
 

• 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?

juj has a memory profiling tool, I don't remember where it is though.
 

• What's the role of the memory initialization file? What does it contain on startup?

It contains what memory is initialized with. So static global variables, etc. If you have printf("hello world"); then that string will be in there somewhere, for example.

- Alon

 

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 emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bruce Mitchener]

On Fri, Dec 19, 2014 at 2:05 AM, Alon Zakai <alon...@gmail.com> wrote:

On Thu, Dec 18, 2014 at 2:00 AM, Warren Seine <warren...@aerys.in> wrote:

• 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?

juj has a memory profiling tool, I don't remember where it is though.

The tool from juj doesn't work under asm.js ... however, my memory tracing tools which are part of emscripten (the UI isn't, but is linked from the docs), should work with asm.js and are documented in the emscripten docs. See the --tracing option to emcc.

 - Bruce

 

[Chad Austin]

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.

--
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 emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Chad Austin

Technical Director, IMVU

http://engineering.imvu.com

http://chadaustin.me

[Warren Seine]

Thank you all for your help.

I will be looking at the trace tool, it should be enlightening.

Chad, thank you. We haven't had any big issues on desktop machines that cannot be explained. But yes, we're trying to stay below 128 MB.

Cheers,

--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/eKKLzvbGOpY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Warren Seine

Founder and CTO of Aerys | aerys.in

Phone: (+33)9 72 28 55 82  /  (+33)6 79 51 64 66