A Thorough Study

of Blink’s Memory

in Real-world Websites

*

*

*

*

{haraken, bashi, hajimehoshi, tasak}@chromium.org

2015 Oct

Memory team projects

• Oilpan
• haraken@, keishi@, peria@, yutak@

​

• Memory reduction (⇐ This talk is about this)
• bashi@, hajimehoshi@, tasak@

​

• Instant tab restore
• kouhei@, tzik@

*

*

Memory reduction

• As of 2015 June, memory reduction was raised as one of the priorities of the web-platform team

​

• At that point, no one knew even what percentage of renderer’s memory is consumed by Blink

​

• Since then, we’ve been working on understanding Blink’s memory usage and identifying sweet spots to reduce it

*

*

Goals of this talk

• Goal 1: Share our findings about Blink’s memory

​

• Goal 2: Propose key projects that (we think) will reduce Blink’s memory

​

• Goal 3: Get more teams involved in the memory reduction efforts

*

*

Understand real-world memory usage

What we have done

• Step 1: Improve tooling (memory-infra)

​

• Step 2: Understand memory usage of real-world websites

*

*

Improve tooling

• As of 2015 June:
• Blink mixed four memory allocators
• PartitionAlloc
• Oilpan
• tcmalloc
• system allocator
• There was no way to profile Blink’s memory

*

*

Improve tooling

• We (mostly) removed tcmalloc and system allocators from Blink
• PartitionAlloc
• Oilpan
• tcmalloc
• system allocator

*

*

Improve tooling

• The London team supported PartitionAlloc and Oilpan in memory-infra

*

*

Improve tooling

• We implemented a per-object-type profiler, which can list up objects frequently allocated
• The profiler will be integrated to memory-infra soon

*

*

Improve tooling

• The London team and we are implementing an allocation-site profiler, which can visualize stack traces of frequently allocated objects
• The profiler will be integrated to memory-infra soon

​

StringImpl 536 KB

<--- AtomicString::AtomicString()

<--- ScriptResource::script()

*

*

Improve tooling

• Summary:
• Now Blink uses only PartitionAlloc and Oilpan
• memory-infra visualizes memory usage of PartitionAlloc and Oilpan
• More detailed profilers (per-object-type profiler & allocation-site profiler) are going to be added to memory-infra

*

*

Understand real worlds

• Now we have great tools :)

​

• The next step is to understand memory usage of real-world websites

​

• Notes about the results shown in this slide:
• They are measured on a device without low-RAM mode. You can find more results in this spreadsheet.
• They are measured after 10 seconds after a page load.

*

*

Understand real worlds

• Break down the memory
• Break down the renderer’s memory
• Renderer = V8 + PartitionAlloc + Oilpan + ...
• Break down the PartitionAlloc’s memory
• PartitionAlloc = Buffer + FastMalloc + Node + Layout
• Break them down into per-object memory
• Buffer = StringImpl + Vector + HashTable + ...

*

*

Break down of renderer’s memory

*

*

Break down of renderer’s memory

• The largest consumer is V8
• V8 consumes 40 - 70% in common cases

​

• The second largest consumer is Blink (PartitionAlloc+Oilpan)
• Blink consumes 10 - 20% in common cases

​

• Some (a lot?) of the memory in Discardable, CC and V8 is retained by Blink

*

*

Break down of PartitionAlloc’s memory

• Preliminary knowledge:
• Since we’ve not yet fully shipped Oilpan, most Blink objects are allocated in PartitionAlloc
• PartitionAlloc has four partitions:
• Node (for Nodes)
• Layout (for LayoutObjects)
• Buffer (for Vectors, HashTables, StringImpls, ArrayBuffers etc)
• FastMalloc (for SharedBuffers and all other objects)

*

*

Break down of PartitionAlloc’s memory

*

*

Break down of PartitionAlloc’s memory

• The largest consumer is the Buffer partition
• StringImpl, Vector, HashTable, ArrayBuffer etc

​

• The second largest consumer is the FastMalloc partition
• SharedBuffer, all DOM objects except for Node and LayoutObject

​

• sizeof(Node) and sizeof(LayoutObject) don’t really matter

*

*

Break down of the Buffer partition

*

*

Break down of the Buffer partition

• The largest consumer is StringImpls larger than 50 KB
• We confirmed that more than 90% of the large StringImpls are JavaScript source code

​

• The second largest consumer is Vectors and HashTables
• We don’t yet know where they come from

*

*

Break down of the FastMalloc partition

*

*

Break down of the FastMalloc partition

• The largest consumer is SharedBuffers
• They are used as backing storage of Resources

​

• Other objects have a very long tail
• The 2nd - 5th largest consumers depend on webpages
• Reducing sizeof(DOM object) is not likely to contribute to reducing Blink’s memory usage

*

*

Summary

• Blink (PartitionAlloc+Oilpan) is the second largest consumer of renderer’s memory
• Blink consumes 10 - 20% in common cases
• Blink retains some of memory in Discardable, CC and V8

​

• Inside Blink, the main memory consumers are:
• Large StringImpls (used by JavaScript source code)
• SharedBuffers (used by Resources)
• Vectors and HashTables

*

*

Goal & Approach

Goal

• Based on the investigation, we defined key 10 pages where Blink’s memory reduction is a key

*

*

Goal

​

​

• Our goal is to reduce Blink’s memory in the key 10 pages by 30% by 2016 Q1

*

*

Goal

• “Blink’s memory” refers to the following two things:
• The amount of memory consumed by PartitionAlloc and Oilpan
• The amount of memory consumed by V8, CC and Skia retained by Blink
• e.g., Blink objects can have a strong reference to a DOM wrapper which retains the entire window object

*

*

Goal

• Should we focus on short-lived apps? Or long-lived apps?
• For short-lived apps, memory after 10 seconds after a page load matters
• For long-lived apps, memory after 1 hour after a page load & a lot of user interactions matters

​

• For now we’re focusing on short-lived apps because short-lived apps would be more important in mobile devices

*

*

Approach

• OK, the goal is now clear:
• Reducing Blink’s memory by 30%

​

• How can we achieve the goal?
• MemoryPurgeController

*

*

Approach

• When Blink should save memory, MemoryPurgeController dispatches MemoryPurgeClient::purgeMemory()

class MemoryPurgeController {

void dispatchPurgeMemory(...) { // Dispatched when Blink should save memory

for (auto& client : m_clients) // Our goal is to purge Blink’s memory by 30%

client->purgeMemory(...);

}

HashSet<MemoryPurgeClient*> m_clients;

};

class MemoryCache : public MemoryPurgeClient {

void purgeMemory(...) override { pruneAll(); } // Example

};

*

*

Approach

• When does MemoryPurgeController dispatch the purgeMemory()?
• When X seconds have passed since a tab became inactive
• When Blink receives MemoryPressureListener’s notifications

*

*

Approach

• What should the purgeMemory() do?
• It is NOT a good idea to implement purgeMemory() on various caches just because they are discardable
• It will just increase code complexity
• It is important to identify caches that have an impact on Blink’s total memory and implement purgeMemory() only on them

*

*

What we’ve learned so far

• Memory reduction based on a “guess” is NOT likely to contribute to the reduction of Blink’s total memory
• We experimented with discarding Blink items each TL listed in this spreadsheet, but most of them didn’t have an impact on Blink’s total memory
• Also reducing sizeof(DOM object) won’t have an impact

*

*

What we’ve learned so far

• It is important to drive the memory reduction more tactically
• Step 1: Fix low-hanging fruits
• Step 2: Identify key projects (sweet spots)
• Step 3: Reduce the memory at a pinpoint

​

​

• What would the key projects be?

*

*

4 key projects

4 key projects

• Compression of large StringImpls (⇒ Memory team)
• More aggressive Resource pruning (⇒ Loading team?)
• Discarding layout trees (⇒ Layout team?)
• Making V8 ⇔ Blink cycles collectable (⇒ V8 team)

*

*

Compression of large StringImpls

• The largest consumer of PartitionAlloc is large StringImpls

​

• More than 90% of the large StringImpls are JavaScript source code
• They are not discardable (used by V8)
• The only option to reduce the memory is to compress the StringImpls

*

*

Compression of large StringImpls

• We confirmed that if we gzip large StringImpls, we can reduce PartitionAlloc’s memory by 10 - 60% (17% in average)

*

*

More aggressive Resource pruning

• The second largest consumer of PartitionAlloc is SharedBuffers

​

• SharedBuffers are used as backing storage of Resources
• Memory reduction on Resources is important

*

*

More aggressive Resource pruning

• Actually, memory reduction on Resources is more important than the data implies because Resources retain memory in Discardable and Skia as well
• Some Resources use locked discardable memory
• Image/FontResources can hold caches in Skia

*

*

More aggressive Resource pruning

• Low-hanging fruits:
• HTMLLinkElement should clear CSSStyleSheetResource when it finishes parsing the stylesheet
• This reduces 1.2 MB from pinterest.com, 800 KB from theverge.com
• GlyphPage should discard GlyphPageTree
• This reduces 200 KB from theverge.com
• FontCustomPlatformData should discard cached font-faces in Skia

*

*

More aggressive Resource pruning

• More aggressive idea:
• Forcibly discard all Resources from an inactive tab
• When the tab is re-activated, fetch the Resource again (hopefully from the network cache) in a way that doesn’t dispatch onload events

*

*

Discarding layout trees

• LayoutObject seems to retain a lot of memory in CC
• CC consumes 10 - 30% of renderer’s memory
• Though LayoutObject itself consumes only 1- 10% of PartitionAlloc

​

• Idea:
• Discard layout trees from an inactive tab
• We can recalculate the layout tree when requested

*

*

Making V8 ⇔ Blink cycles collectable

• V8 is the largest consumer of renderer’s memory
• V8 consumes 40 - 70% of renderer’s memory

​

• At the very least, Blink should not be the culprit of V8 memory leaks

*

*

Making V8 ⇔ Blink cycles collectable

• Example: e = new CustomEvent("foo", {detail: new Error()});
• This was a cause of a lot of window leaks in Polymer apps

*

*

Making V8 ⇔ Blink cycles collectable

• A V8 object has a strong reference to the window object that created the V8 object
• Thus if a Blink object retains a v8::Persistent handle to the V8 object, it retains the entire window object...

*

*

Making V8 ⇔ Blink cycles collectable

• Idea: Remove all v8::Persistent handles by making V8 ⇔ Blink cycles collectable
• All V8 leaks caused by Blink will be gone

*

*

Summary

• 4 key projects:
• Compression of large StringImpls (⇒ Memory team)
• More aggressive Resource pruning (⇒ Loading team?)
• Discarding layout trees (⇒ Layout team?)
• Making V8 ⇔ Blink cycles collectable (⇒ V8 team)

​

• We want to delegate the reduction work to each team (i.e., experts :-)

*

*

Getting more teams involved

Getting more teams involved

• Memory reduction is the priority of the web-platform team
• We want to get more teams involved on the reduction efforts
• Then we can move faster

*

*

Getting more teams involved

• That said, it is NOT a good idea to start memory reduction based on a “guess”
• Reducing sizeof(DOM object) won’t have an impact
• Discarding caches won’t have an impact in most cases

*

*

Getting more teams involved

• So the memory team will focus on:
• Improving tooling
• Understanding Blink’s memory usage
• Identifying sweet spots that will have a large impact

​

• We may delegate the actual reduction efforts to the team that owns the area
• We’ll kick off a discussion soon :)

*

*