Maximum amount of consumable memory per tab

7,351 views
Skip to first unread message

tkobay...@gmail.com

unread,
Nov 15, 2017, 3:51:07 AM11/15/17
to Chromium-dev
Hi all.

[Question]
In Google Chrome (64bit), what is the maximum memory capacity per tab that JavaScript can consume? Is there a way to increase it?

[BackGround]
In order to know the marginal performance of the Chrome browser for Web application development, I created and executed JavaScript code that intentionally causes memory leak, but when the consumption memory amount of the tab becomes about 2 GB, the out-of-memory error Occurred. (I checked consumption memory in JavaScript memory column of Chrome's task manager)
I expected that chrome would use the full memory of the PC, but at that point the memory of the PC had more than 6 GB (confirmed by the Windows Task Manager).
So, I ask [Question]

I saw below comment, but I cannot find evidence material or design document.
We limit to 4Gb because certain types of attacks rely on being able to allocate > 4Gb of memory.

[environment]
OS: Windows 10 Pro version 1607
HW Memory: 16GB
CPU: Intel Core i7-4710MQ (2.5GHz)
Browser: Google Chrome 62.0.3202.89(Official Build)(64bit)

Thank you.

Primiano Tucci

unread,
Nov 15, 2017, 4:30:32 AM11/15/17
to tkobay...@gmail.com, Chromium-dev
In at least two platforms (windows and Linux afaik) the sandbox puts a hard limit to the virtual memory of the renderer. That limit doesn't depend on how much memory your pc has. Iirc the limit is precisely 2gb (which matches your observation), or 2gb on one platform and 4gb on the other, can't remember on top of my head.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/ede933c9-d623-40cb-8633-50b2256f7828%40chromium.org.

tkobay...@gmail.com

unread,
Nov 15, 2017, 9:21:39 PM11/15/17
to Chromium-dev
Thank you for your reply and information.
I did not know much about Chromium's architecture and your reply was so helpful.
Although I could not find the document that question, so I look up code, the amount allocated memory to the renderer process for Windows seems to match 2 GB. (I cannot read Objective-c or c++ code, so may be wrong...)
src/sandbox/win/src/sandbox_nt_util.cc

Thank you.

2017年11月15日水曜日 18時30分32秒 UTC+9 Primiano Tucci:

Joe Shmoe

unread,
Mar 28, 2018, 8:34:22 PM3/28/18
to Chromium-dev, tkobay...@gmail.com
I have DirecTV Now and Sling, and they're both crashing their respective Chrome tabs on a regular basis because they're bumping up against this 4GB per-tab memory limit.  As such, I'm not so sure that your 2GB figure is accurate, at least for Windows.  All I can tell you is that I have 64GB of RAM in my rig; I don't give two hoots if the tab uses more than 4GB.  I do care, however, if it crashes while I'm watching the news, or a movie.


Afshin Jafari

unread,
Jan 21, 2019, 11:37:27 PM1/21/19
to Chromium-dev, tkobay...@gmail.com
Hi Joe,
Have you got any chance overcome this limit?
I've been searching for an answer, couldn't find any result and and person willing to help!
cheers,

-A

Peter Kasting

unread,
Jan 22, 2019, 12:52:45 AM1/22/19
to tkobay...@gmail.com, Chromium-dev
On Wed, Nov 15, 2017 at 6:21 PM <tkobay...@gmail.com> wrote:
Thank you for your reply and information.
I did not know much about Chromium's architecture and your reply was so helpful.
Although I could not find the document that question, so I look up code, the amount allocated memory to the renderer process for Windows seems to match 2 GB. (I cannot read Objective-c or c++ code, so may be wrong...)
src/sandbox/win/src/sandbox_nt_util.cc

Note also that if you're running 32-bit Chrome, you can't allocate more than 2 GB, because that's the process limit for a 32-bit Windows process.

I wouldn't be surprised if the limit was "2 GB on 32-bit Windows due to OS, 4 GB elsewhere due to Chrome-imposed limits".  But I don't actually know.

PK

Yuta Kitamura

unread,
Jan 22, 2019, 1:05:07 AM1/22/19
to Peter Kasting, tkobay...@gmail.com, Chromium-dev
Even on 64-bit OS, we impose deliberate 2GB limits in each renderer process -- V8, Blink memory allocator etc. Basically you can't lift those limits.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

Afshin Jafari

unread,
Jan 23, 2019, 7:29:30 PM1/23/19
to Chromium-dev, pkas...@chromium.org, tkobay...@gmail.com
Silly question, is that the only place that the limit enforced?

/win/src/sandbox_nt_util.cc

ie, can I rebuild with larger value to get more memory per tab?

regards,

Daniel Bratell

unread,
Jan 24, 2019, 6:50:38 AM1/24/19
to Chromium-dev, Afshin Jafari, pkas...@chromium.org, tkobay...@gmail.com
It is possible you get a bit more memory into a process that way, but if anyone wants to remove the 2 GB/32-bit limit completely there is probably a lot of places that need to change. Another place (of many) is PartitionAlloc, a commonly used internal allocator (what yutak called Blink memory allocator). It's just been an implicit 2 GB limit for so long that it is impossible to know how many places that implicitly or explicitly depend on it.

Eventually this limit might have to be addressed, but for now it also acts as a protection against runaway sites. Nothing prevents a site from allocating memory, but if they try to allocate more than 2 GB that will kill the renderer which is at least better than consuming all the RAM in the machine.

If there was some particular operation a site did that accidentally hit the limit, the first approach would be to try to reduce its memory usage.  [Looking at Google Docs/Sheet/Whatever]

/Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/51661fa0-6e68-458f-ab09-8ab9c4c18164%40chromium.org.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

Sean Wieland

unread,
Apr 15, 2019, 11:22:40 AM4/15/19
to Chromium-dev, afsh...@gmail.com, pkas...@chromium.org, tkobay...@gmail.com
This is outrageous.  How astonishingly shortsighted.  I specifically bought the new MacMini with 64GB of RAM so that I wouldn't have these problems of tabs crashing, as I'm a tab hoarder and sites like Facebook with heavy javascript usage are gluttons for RAM -- but I can increase the supply of resources rather than waiting for sites to be more efficient with their code.  Moore's Law in action.  Or as George Gilder said, "waste transistors".  Humans are expensive and hardware is cheap.

There truly is no way to recompile Chrome / Chromium to lift these hard limits?  I can always expand how much RAM I have, but I cannot abide tabs crashing.


On Thursday, January 24, 2019 at 6:50:38 AM UTC-5, Daniel Bratell wrote:
It is possible you get a bit more memory into a process that way, but if anyone wants to remove the 2 GB/32-bit limit completely there is probably a lot of places that need to change. Another place (of many) is PartitionAlloc, a commonly used internal allocator (what yutak called Blink memory allocator). It's just been an implicit 2 GB limit for so long that it is impossible to know how many places that implicitly or explicitly depend on it.

Eventually this limit might have to be addressed, but for now it also acts as a protection against runaway sites. Nothing prevents a site from allocating memory, but if they try to allocate more than 2 GB that will kill the renderer which is at least better than consuming all the RAM in the machine.

If there was some particular operation a site did that accidentally hit the limit, the first approach would be to try to reduce its memory usage.  [Looking at Google Docs/Sheet/Whatever]

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to chromi...@chromium.org.

Yuta Kitamura

unread,
Apr 15, 2019, 10:46:35 PM4/15/19
to sean...@gmail.com, Chromium-dev, afsh...@gmail.com, Peter Kasting, tkobay...@gmail.com
On Tue, Apr 16, 2019 at 12:20 AM Sean Wieland <sean...@gmail.com> wrote:
This is outrageous.  How astonishingly shortsighted.  I specifically bought the new MacMini with 64GB of RAM so that I wouldn't have these problems of tabs crashing, as I'm a tab hoarder and sites like Facebook with heavy javascript usage are gluttons for RAM -- but I can increase the supply of resources rather than waiting for sites to be more efficient with their code.  Moore's Law in action.  Or as George Gilder said, "waste transistors".  Humans are expensive and hardware is cheap.

There truly is no way to recompile Chrome / Chromium to lift these hard limits?  I can always expand how much RAM I have, but I cannot abide tabs crashing.

It's not that easy. There's no way to lift those limits for now. You need to fix a lot of code to make renderers consume larger memory -- we have code that only works under 2GB/4GB assumptions and we also rely on many optimizations that are only possible within those limits. Lifting the limits is a rather complex project.
 

Andrew Skalkin

unread,
Dec 12, 2019, 1:19:06 PM12/12/19
to Chromium-dev, sean...@gmail.com, afsh...@gmail.com, pkas...@chromium.org, tkobay...@gmail.com
I wonder if there are any ongoing efforts to increase these limits? With browsers becoming mini-OSes and web applications now being able to process a lot of data on the client side (especially with technologies like WebAssembly), I can imagine this being a very popular request. For instance, our company is developing a data analytics and visualization platform that runs completely in the browser. Right now, we can process tens of millions of rows on the client, but have to rely on a server for doing more. Our clients would love to be able to work with billions of rows completely in the browser: https://datagrok.ai/

forbiddenera

unread,
Sep 11, 2020, 6:04:58 PM9/11/20
to Chromium-dev, ska...@gmail.com, sean...@gmail.com, afsh...@gmail.com, Peter Kasting, tkobay...@gmail.com
+1; Google says they want us to be able to make any app in the browser.

2-4GB not enough anymore.

Eric Lawrence

unread,
Sep 16, 2020, 9:13:20 PM9/16/20
to Chromium-dev, forbiddenera, ska...@gmail.com, sean...@gmail.com, afsh...@gmail.com, Peter Kasting, tkobay...@gmail.com
FWIW, the limit for 64-bit processes has been 8-16GB for some time now. Discussion in https://textslashplain.com/2020/09/15/browser-memory-limits/

Bruce Dawson

unread,
Sep 18, 2020, 1:49:52 AM9/18/20
to Chromium-dev, eri...@microsoft.com, forbiddenera, ska...@gmail.com, sean...@gmail.com, afsh...@gmail.com, Peter Kasting, tkobay...@gmail.com
Thanks for that article - excellent as always. One "correction", of sorts. You say "on Windows, a 32bit process can only allocate 2gb" but that is not quite the case. In fact, 32-bit processes that are tagged as large-address-aware (Chrome is) and are running on 64-bit Windows (Chrome usually is) can allocate 4gb of memory.

And yet, 32-bit Chrome on your test page stops at 2 GB (roughly). But that is not a Windows limitation. That can be seen by running vmmap on your test page and seeing that when it maxes out it has actually allocated (including image, stacks, private memory, and other) about 2.4 gb.

Maybe it's a pointless distinction, but a 32-bit process on Windows can allocate more than 2 GiB, but 32-bit Chrome adds additional restrictions, at least for JavaScript memory. I don't remember where the restriction comes from.

Alex Gough

unread,
Sep 22, 2020, 1:40:51 PM9/22/20
to Chromium-dev, Bruce Dawson, eri...@microsoft.com, forbiddenera, ska...@gmail.com, sean...@gmail.com, afsh...@gmail.com, Peter Kasting, tkobay...@gmail.com
FWIW these are the current limits for 64bit, if you have a use case that needs more we are receptive to bugs that ask to increase the limits:

  • Renderer

    • Per-process (Job, Rlimit) ~ 16 GiB (less if less system memory)

    • V8 Isolate 4GB (reservation)

    • V8 code range 128 MiB

    • Wasm Memory 4 GiB kSpecMaxWasmMaximumMemoryPages

    • Wasm Code Size 2 GiB kMaxWasmCodeMemory

    • Single partition_alloc allocation INT_MAX

    • Per-slab allocation limit from allocator shims: 2 GiB.

  • GPU

    • Windows, Linux: 64 GiB (less if less system memory)

  • Network

    • Windows: 16 GiB

  • Other Utilities

    • Windows: 16 GiB via default policies

  • Browser

    • None


Reply all
Reply to author
Forward
0 new messages