Issue 239803: build Chrome on Windows with LARGEADDRESSAWARE

oops.  I meant  bug 226897 .

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.

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.

@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.

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

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.

This will break SyzyASAN as we currently don't handle LAA processes. Being addressed here: https://codereview.chromium.org/17348007/edit

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

Moving all non essential bugs to the next Milestone.

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

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.