jf.pamb...@ thanks for your report.  Indeed this is a multifaceted problem.

For 1), other than physical available memory, virtual memory system on
each platform, memory layout for each process, and per-process limits
vary wildly to guarantee that "at least this amount of memory is available
to your web app" in general.

I have no idea off-hand why 64bit linux process has 1.8GB limitation,
so one possible thing Chrome might fix could be to raise the memory limit
for each tab on Linux. We only distribute 64bit builds of Chrome, so each
process should have much wider address space than 4GB, although the usable
JS heap memory would be restricted by various factors.

(btw, I ran your jsfiddle[0] on my workstation which has plenty of RAM
and confirmed the tab crashes around 2GB)

For 2), I thought nowadays tabs opened from Gmail doesn't share the renderer
process with Gmail if the domain is different. So if you see tabs opened from
Gmail share the same process with Gmail, it smells a bug to me.
Could you file a separate bug for this?


If you would not mind, we'd like to reuse this issue to track the
memory limit of Linux tab exclusively, and for any other actionable
issues, could you file a separate bug?


FYI, Google has some advice on tackling on memory issues on Chrome:
https://developers.google.com/web/tools/chrome-devtools/memory-problems/?hl=en

Thanks for the quick and helpful response.

I will open a new ticket to track the site-instance process issue.

As for memory consumption tips, our product deals with visualization of large data sets that can exceed one gigabyte. Once settled, after loading the data, the overhead of the application is about 100 MB (i.e. total mem usage = the large set + ~100 MB). 

With devtools and the site-instance model, I see 'Aw snap' between 20 to 30 times a day.. so, if there is anything I can do to help..

I opened  Issue 704521 .

Also, I am attaching the screenshots from the original report for posterity.

Deleted: 20170322085607.png 29.0 KB

	20170322085607.png 29.0 KB View Download

Deleted: 20170322085852.png 11.1 KB

	20170322085852.png 11.1 KB View Download

I learned today that the memory allocator used in Blink (PartitionAlloc)
uses a dedicated memory pool (a partition) for array buffer, and each
partition cannot exceed 4GB as 32bit pointer is used internally.
(that contradicts that on Mac 8+GB? could be allocated, though.)

Still, the reason why the memory is limited to 2GB on Linux is unclear.

Someone responsible for MemoryAllocator, can you explain why the data usage
is capped around ~2GB where more plenty of memory is available?

For the original question, jf.pamb...@, how much memory do you need for
your application to run on Chrome Linux?
To allow much more memory (>4G), IIUC Blink needs considerable change
that cannot happen in short term and in that case general advice would be
give up using Chrome for your application, unfortunately.

Thanks for your response. To give some context, we are building a medical application geared toward radiologists. 

The memory requirements depend on the dataset that is being visualize. I don't see any current use cases that would require >4 GB per tab, but ~2 GB is possible. However, these datasets will become larger as technology continues to evolve and 4 GB might not be enough in just a few years. Furthermore, I see OOM issues with much smaller memory usage with the devtools opened.

In addition, opening multiple datasets in multiple tabs is a common workflow. The site-instance process sharing model (where all grouped tabs share the same 2 GB memory pool) exacerbate this issue considerably. We are going to try the workaround proposed in #704521, but I would be eternally grateful it the memory limit on Linux 64 bit could be raised to be on par with other platforms.

Thanks for the feedback!

Please note that with developer tools open, you may see more memory leaking,
as garbage collecter cannot collect unused memory because the tool is also
grabbing some reference. And also devtools uses memory on its own, of course.

I have been using Electron lately, and to my surprise, it is not plagued with that issue.

On chrome 61 (which was released today), I still get Aw snaps extremely easily. I just need to open 2-3 medical exam tabs from our application and they will all crash simultaneously.

I can also get this issue consistently by opening gotomeeting links from Office 365 as they each take >700 MB of memory and are pooled together in the same process.

However, I notice that Electron does not have this issue. I can easily allocate 20+ GB of typed array (see attachement, I did 'electron http://example.com', open the console, spam new Uint8Array(1*1024*1024*1024)).

I can only allocate one such array before I get into issues (either Array buffer allocation failed, or uncatchable 'Aw snaps' in real applications) in Chrome 61.

How can this be? Obviously, it can be fixed..

Deleted: 20170906082137_3246bc7fd2fca520.png 282 KB

	20170906082137_3246bc7fd2fca520.png 282 KB View Download

Looks like this is mostly fixed. I noticed on Version 62.0.3202.94.
I can now allocated up to 8 GB per process group. Once I reach the limit, I now get a catchable buffer allocation error instead of 'aw snaps'.

Keep up the good work!

Is this still an issue?

The situation seems to have improved since I can now allocate up to 8gb in the console with new Uint8Array(1*1024*1024*1024) and I will get 'Array buffer allocation failed' instead of 'Aw snap' when that limit is reached.

However, our application can open multiple tabs that will end up in the same process due to Chrome's process sharing model. Each tab consume about 1 GB. Opening two concurrent tabs works flawlessly, but adding a third tab will result in 'Aw snaps' across all tabs with 100% reproducibility.

This was observed on Linux with Chromium Version 66.0.3359.139 (Official Build).