Overview of memory consumption in renderer process

[Kenichi Ishibashi]

Hi,

To answer the frequently-asked-question "how much of the renderer memory is consumed by Blink?", we investigated the breakdown of the renderer memory in real-world websites using memory-infra. The result is summarized in this document:

https://docs.google.com/document/d/1zlGQkwkWEu5LUg-CrZHHRuhDtZcuvrRv8bjdC8-noaU/edit#heading=h.a898thpufhtq

In short, we found that Blink is consuming 10 - 50% of the renderer memory in low-memory mobile devices and 10 - 35% of the renderer memory in desktops. This clearly means that Blink needs a serious memory reduction.

Before starting the actual memory reduction, it is important to have a metric that keeps track of the reduction work. Based on the above result, we defined the top 10 webpages where Blink's memory reduction is a key [1]. Our project goal is to reduce the Blink's memory numbers of the top 10 pages by 30% by the end of 2015. We hope that fixing the memory issues of the top 10 pages will fix memory issues of other webpages as well. Specifically, we're planning to:

- Support low-memory mode (for low-end mobile devices).

- Support MemoryPressureListener (for near-OOM situations).

- Support RenderThreadImpl::OnRendererHidden (for more aggressively reducing memory of background tabs).

- Discard as many discardable things in Blink [2] as possible in the above three scenarios (e.g., drop the entire layout object tree).

- Reduce the number/size of objects that are detected as problematic in a per-object-type profiler of PartitionAlloc & Oilpan.

Any comments are appreciated :)

Note that this is just the first version of our memory-investigation efforts. hajimehoshi@ is now implementing the per-object-type profiler for PartitionAlloc, which will list up the top 10 Blink objects that need size/number reductions. tasak@ is now replacing all allocators in the renderer process with PartitionAlloc to get all the objects under our control. This will make it possible to find memory problems in Skia, content/ and all other components in the renderer process. We'll share the result once we get something interesting :)

[1] https://docs.google.com/document/d/1QYCM5UeX90OodWt1vl6jlShhv8kg0HnXY7SdPCyILRs/edit

[2] https://docs.google.com/document/d/13RMN1dExjQdnSjEaEgxOxdakX8UndbqjAmc2mi_DSp0/edit

Thanks,

[Paweł Hajdan, Jr.]

On Fri, Jul 31, 2015 at 10:17 AM, Kenichi Ishibashi <ba...@chromium.org> wrote:

In short, we found that Blink is consuming 10 - 50% of the renderer memory in low-memory mobile devices and 10 - 35% of the renderer memory in desktops. This clearly means that Blink needs a serious memory reduction.

Curious, what's using the remaining part of memory? From above sentence it seems that Blink actually uses minority of the renderer memory.

Paweł

[Kentaro Hara]

V8, malloc (e.g., Skia, content/ and a bunch of things that use 'global new') and discardable. See the breakdown in the spreadsheet:

https://docs.google.com/spreadsheets/d/1nDmgP2SaFS_CmqFoNW4WDGYWkFl6CPUWmiVAoySv9bE/edit#gid=391210811

 

Paweł

--

Kentaro Hara, Tokyo, Japan

[Stefan Zager]

On Fri, Jul 31, 2015 at 1:17 AM Kenichi Ishibashi <ba...@chromium.org> wrote:

In short, we found that Blink is consuming 10 - 50% of the renderer memory in low-memory mobile devices and 10 - 35% of the renderer memory in desktops. This clearly means that Blink needs a serious memory reduction.

What's the primary concern here: the actual percentages, or the fact that the percentage is higher for low-memory mobile?

[Kentaro Hara]

We want to reduce the memory of the renderer process. That is one of the top priorities of the platform team. The fact that Blink is consuming 10 - 50% of the renderer memory indicates that Blink is a key place to reduce the renderer memory.

Historically, Blink has not seriously worked on the memory reduction because Blink was consuming <5% of the renderer memory one year ago (i.e., if we wanted to reduce the renderer memory, Blink was not the key place to slim down. V8 and GPU were the places). That is no longer true today.

[Stefan Zager]

On Fri, Jul 31, 2015 at 12:14 PM Kentaro Hara <har...@chromium.org> wrote:

Historically, Blink has not seriously worked on the memory reduction because Blink was consuming <5% of the renderer memory one year ago (i.e., if we wanted to reduce the renderer memory, Blink was not the key place to slim down. V8 and GPU were the places). That is no longer true today.

That is a crazy regression in just one year.  Has anyone tried to bisect it?

[Kentaro Hara]

It is not necessarily a regression. I guess that the main reason that increased the Blink's contribution would be that V8 and GPU has reduced their memory in the past one year. That said, it is hard to verify the hypothesis because the ways we collected the memory numbers are completely different between the last year's measurement (based on Deep Memory Profiler) and today's measurement (based on memory-infra).

[Stefan Zager]

OK, then I'm still interested in answer to this question: what exactly is concerning about the new batch of numbers -- is it the actual percentages, or the fact that the percentage is higher for low-power mobile devices?  I'm not trying to throw shade on Kenichi's conclusion, I just want to understand.

Thanks,

Stefan

[Levi Weintraub]

Looking at the Key Pages for Blink Memory Usage Reduction, larger memory sites seems to loosely correlate with the lower partition alloc percentages. Do we have evidence of memory-intensive mobile sites that also have large partition alloc percentages?

[Kentaro Hara]

We need to reduce the renderer memory (are you asking why we do this?). The fact that PartitionAlloc is consuming >30% of the renderer memory in popular websites indicates that we need to reduce PartitionAlloc's memory in order to reduce the renderer memory. (Note: V8 and GPU have been already doing a lot of work to reduce their memory.)

[Kentaro Hara]

On Fri, Jul 31, 2015 at 11:18 PM, Levi Weintraub <le...@chromium.org> wrote:

Looking at the Key Pages for Blink Memory Usage Reduction, larger memory sites seems to loosely correlate with the lower partition alloc percentages. Do we have evidence of memory-intensive mobile sites that also have large partition alloc percentages?

I think you're right. It seems that memory-intensive mobile sites tend to spend most of their memory in V8 and GPU, although there are a non-negligible number of mobile sites where PartitoinAlloc's rate is >30%.

Here I'm not intending to point out that reducing PartitionAlloc is more important than reducing V8 and GPU. The point is that PartitionAlloc's memory usage is no longer ignorable (it is no longer <5%) and thus we need to take an action in Blink as well as V8 and GPU :)

Quoted from the document:

Site	Total (MB)	Rate of PartitionAlloc (%)	Page set/Configuration
pinterest.com	47.6	51.6	key_mobile / low-RAM
facebook.com	53.7	46.8	top10_mobile / low-RAM
theverge.com	52.4	43.0	key_mobile / low-RAM
worldjournal.com	86.9	16.5	key_mobile / low-RAM
wikipedia.org	28.6	32.0	key_mobile / low-RAM
reddit.com	27.2	33.7	key_mobile / low-RAM
wordpress.com	37.6	33.4	key_mobile / low-RAM
plus.google.com	19.4	25.3	key_mobile / low-RAM
blogspot.com	323	14.7	top7_stress / Desktop
mail.google.com	127.9	15.7	top7_stress / Desktop

On Fri, Jul 31, 2015 at 2:05 PM, Stefan Zager <sza...@chromium.org> wrote:

On Fri, Jul 31, 2015 at 12:31 PM Kentaro Hara <har...@chromium.org> wrote:

On Fri, Jul 31, 2015 at 9:25 PM, Stefan Zager <sza...@chromium.org> wrote:

On Fri, Jul 31, 2015 at 12:14 PM Kentaro Hara <har...@chromium.org> wrote:

Historically, Blink has not seriously worked on the memory reduction because Blink was consuming <5% of the renderer memory one year ago (i.e., if we wanted to reduce the renderer memory, Blink was not the key place to slim down. V8 and GPU were the places). That is no longer true today.

That is a crazy regression in just one year.  Has anyone tried to bisect it?

It is not necessarily a regression. I guess that the main reason that increased the Blink's contribution would be that V8 and GPU has reduced their memory in the past one year. That said, it is hard to verify the hypothesis because the ways we collected the memory numbers are completely different between the last year's measurement (based on Deep Memory Profiler) and today's measurement (based on memory-infra).

OK, then I'm still interested in answer to this question: what exactly is concerning about the new batch of numbers -- is it the actual percentages, or the fact that the percentage is higher for low-power mobile devices?  I'm not trying to throw shade on Kenichi's conclusion, I just want to understand.

Thanks,

Stefan