From my limited understanding, the ADDR_COMPAT_LAYOUT personality flag reverts to the older mmap implementation that effectively wastes 1gb of address space: http://lwn.net/Articles/90311 Getting an extra gb of address space would be extremely useful. My rough measurements show that a webapp running as the only tab in a fresh browser can only get about 600mb before OOMing. We need this much or more to run Emscripten-ported asm.js apps (e.g., http://beta.unity3d.com/jonas/AngryBots/ uses ~514mb, leaving the browser very OOM-y). If you search for ADDR_COMPAT_LAYOUT in: https://android.googlesource.com/platform/frameworks/base/+/cd92588/cmds/app_process/app_main.cpp it would appear that (assuming this source is current; I have no idea) that ADDR_COMPAT_LAYOUT is indeed set unless the NO_ADDR_COMPAT_LAYOUT_FIXUP env var is set. Could anyone help me try this out? Or perhaps someone already knows more about this situation?
Component: General → Build Config & IDE Support
Summary: figure out how to clear ADDR_COMPAT_LAYOUT to win 1gb → Figure out how to clear ADDR_COMPAT_LAYOUT to win 1GB
The logic was in init.c at one point. Not sure if this made it into a release: https://code.google.com/p/android-source-browsing/source/detail?r=01b1dee0ab7ad649760f9d8a7cead2a3f6d9cf70&name=master&repo=platform--system--core&path=/init/init.c
If all you need to do is set an environment variable for the process Fennec runs in, you should be able to do that by setting a startup wrapper for the process. See the bottom of my blog post at  (the part starting at "The final piece of the puzzle") for an example of how to do this. You'll have to remove the valgrind bits from this snippets obviously and just exec $* in the wrapper.  https://staktrace.com/spout/entry.php?id=762
Fennec can be launched with environment variables set using: am start -n org.mozilla.fennec/.App --es env0 NO_ADDR_COMPAT_LAYOUT_FIXUP=1 However I thought I tried this on a n4 with no effect, but should double check.
To be more specific, the env0 argument passed to |am start| is processed at in Java at , during the Java code set-up for loading Gecko. Both Gecko and the Java code/dalvikvm run in the same Android process, which is already initialized at that point.  http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/mozglue/GeckoLoader.java.in?rev=4354d5ed2311#130
(In reply to Kartikaya Gupta (email:firstname.lastname@example.org) from comment #4) > The approach in comment 3 only sets the environment variables for when gecko > starts up. The stuff comment 0 is referring to is in the Android zygote > process which happens earlier. You need the wrapper method to set > environment variables when that runs. Thank you, that does explain why the command in comment 3 did not work.
Interestingly Android 5 on the Nexus 4 and Nexus 7 do not set the ADDR_COMPAT_LAYOUT personality bit. The personality on the Nexus 4 is 0x00800000 and on the Nexux 7 0x00840000. However the address map was not quite what I expected and still appears to grow up from 0x40000000. The address space below 0x40000000 is now being used in part by dalvik so this might be making more address space available above 0x4000000. It was possible to allocate a 768M asm.js heap buffer on the 1G Nexus 7.
You need to log in before you can comment on or make changes to this bug.