New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Blocking:
issue 245513



Sign in to add a comment

build Chrome on Windows with LARGEADDRESSAWARE

Reported by erikkay@chromium.org, May 10 2013 Back to list

Issue description

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

 
oops.  I meant  bug 226897 .

Comment 2 by kbr@chromium.org, May 11 2013

Cc: kbr@chromium.org

Comment 3 by kbr@chromium.org, May 21 2013

Labels: M-29
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.

Comment 4 by cpu@chromium.org, 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.

Comment 5 by kbr@chromium.org, May 21 2013

Cc: wiltzius@chromium.org

Comment 6 by kbr@chromium.org, May 21 2013

Owner: kbr@chromium.org
Status: Assigned
Blocking: chromium:245513

Comment 8 by cpu@chromium.org, Jun 14 2013

Cc: rvargas@chromium.org

Comment 9 by kbr@chromium.org, 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.

Project Member

Comment 10 by bugdroid1@chromium.org, Jun 15 2013

------------------------------------------------------------------------
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
------------------------------------------------------------------------
Cc: ranjitkan@chromium.org
Labels: TE-Verified-29.0.1540.1
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
Project Member

Comment 13 by bugdroid1@chromium.org, Jun 20 2013

------------------------------------------------------------------------
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
------------------------------------------------------------------------
Labels: -M-29 MovedFrom-29 M-30
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?

Comment 16 by kbr@chromium.org, Aug 13 2013

Status: Fixed
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.

Comment 17 by laforge@google.com, Sep 13 2013

Labels: Hotlist-SyzyASAN
Labels: -Hotlist-SyzyASAN

Sign in to add a comment