|
||||||||||||
Issue descriptionWe should build Chrome with LARGEADDRESSAWARE. This will give it access to more of the address space on a large percentage of our userbase, and could reduce out of memory crashers caused by address space fragmentation. A specific use case is that it will fix the OOM from the Unreal Engine emscripten demo described in bug 226987 . May 11 2013,
May 21 2013,
What process if any do we need to follow to make this change? I am interested in doing it for M29 because that's where the other fix for this demo has been made. I will put out a CL if there are no objections. May 21 2013,sacrifice a brown chicken in any nearby river at exactly midnight of the summer solstice while thinking on a perfectly green chrome waterfall. Or just simply change the linker flags of chrome.exe in gyp somewhere somehow. BTW you need a feature bug with milestone and all the toppings. May 21 2013,
May 21 2013,
May 31 2013,
Jun 14 2013,
Jun 14 2013,@cpu asked me in https://codereview.chromium.org/17029013/ to update this bug in 6 weeks' time with the UMA memory usage of the new Chrome with this flag, to understand whether it should be kept. Jun 15 2013, Project Member------------------------------------------------------------------------ r206560 | kbr@chromium.org | 2013-06-15T05:02:35.723479Z Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=206560&r2=206559&pathrev=206560 Added /LARGEADDRESSAWARE linker flag on Windows. Allows Unreal Engine Epic Citadel demo transpiled to Emscripten to run in Chrome on 32-bit Windows. BUG= 239803 TEST=http://www.unrealengine.com/html5 on Windows Review URL: https://chromiumcodereview.appspot.com/17029013 ------------------------------------------------------------------------ Jun 18 2013,
Tested this on Win 7 Canary Version 29.0.1540.1 (Official Build 206633) by loading URL:http://www.unrealengine.com/html5 and was able to play the demo without any crashes. Thanks. Jun 18 2013,This will break SyzyASAN as we currently don't handle LAA processes. Being addressed here: https://codereview.chromium.org/17348007/edit Jun 20 2013, Project Member------------------------------------------------------------------------ r207398 | chrisha@chromium.org | 2013-06-20T10:47:43.374400Z Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=207398&r2=207397&pathrev=207398 Disable large address aware mode for SyzyASAN builds. SyzyASAN requires double the shadow memory to accomodate this change, which would incur a significantly higher OOM rate for canary channel users. This reverts https://codereview.chromium.org/17029013/ when 'asan=1' is defined. BUG=https://code.google.com/p/sawbuck/issues/detail?id=72 BUG= 239803 Review URL: https://chromiumcodereview.appspot.com/17348007 ------------------------------------------------------------------------ Jun 26 2013,
Moving all non essential bugs to the next Milestone. Jul 16 2013,[From https://chromiumcodereview.appspot.com/17029013 ] On 2013/06/17 18:54:37, Ken Russell wrote: > I personally doubt that there is any > stability risk. It is a fact that allocations would be able to cross the > 0x7FFFFFFF -> 0x80000000 boundary for the first time on Windows, but this may > have been possible on other 32-bit platforms for some time now, so I don't think > any new behaviors or bugs in pointer arithmetic will be exposed. Still, we > should closely watch the canaries over the next week or so to confirm. Have you tried using the MEM_TOP_DOWN or the registry trick to force allocations to allocate from higher addresses before lower addresses? [ See http://msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx ] I'm pretty sure there's quite some Windows-specific code which was never/barely tested under LAA conditions. --- Also note on 32-bit systems the LAA flag only affects users with altered boot.ini, however on 64-bit systems it will give the processes 4GB of address space. That said, it seems to improve things only for Win x64 users having 32-bit Chrome? Aug 13 2013,
I haven't tried changing the memory allocation patterns, but this has managed to stick for a while without increasing crash rates so I'm marking it fixed. It does make certain large apps like the Epic Citadel demo work in Chrome so I think it's worth keeping at least until a 64-bit build of Chrome is available for Windows. Marking Fixed. If additional work is needed please file a follow-on bug. Sep 13 2013,
Sep 16 2013,
|
||||||||||||
►
Sign in to add a comment |
Comment 1 by erikkay@chromium.org, May 10 2013