Blink Memory Reduction

(@BlinkOn5)

*

*

*

*

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

2015 Nov

Memory team projects

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

​

• Memory reduction (⇐ This talk is about this)
• haraken@, bashi@, hajimehoshi@, tasak@
• Working with primiano@, ssid@, ruuda@

​

• Tab resource reclaiming
• kouhei@, tzik@

*

*

History

• 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 and identifying sweet spots to reduce it

*

*

Strategy

• Three steps for memory reduction:
• Tooling
• Understanding
• Reducing

*

*

Strategy

• Step 1: Tooling
• Build up memory-infra and provide consistent data to break down the renderer’s memory into pieces
• Provide reproducible telemetry benchmarks and metrics with which developers can keep track of their reduction efforts

*

*

Strategy

• Step 2: Understanding
• Using the tools, identify sweet spots that need reduction

*

*

Strategy

• Step 3: Reducing
• Brainstorm ideas with teams who own the code area
• Enable the teams to get involved in the reduction
• Getting more teams involved is key to have a bigger impact

*

*

Agenda of this talk

• Tooling
• Provide consistent data
• Provide reproducible benchmarks and metrics
• Understanding
• Identify sweet spots
• Reducing
• Brainstorm ideas
• Enable more teams to get involved

*

*

Tooling

Allocator unification

• As of 2015 June, Blink mixed four memory allocators
• PartitionAlloc
• Oilpan
• tcmalloc
• system allocator

​

• It was crazy...

*

*

Allocator unification

• We removed tcmalloc and system allocator from Blink
• PartitionAlloc
• Oilpan
• tcmalloc
• system allocator

​

• Note: Why only from Blink?
• We experimented with unifying all allocators in Chromium but couldn’t observe any clear performance/memory win

*

*

memory-infra

• We supported PartitionAlloc and Oilpan in memory-infra
• We’re adding more detailed profiling information to get more understanding

*

*

More detailed profiling

• What types of objects and how many objects are allocated in Blink (per-object-type profiler)

*

*

More detailed profiling

• Where large objects are allocated (allocation-site profiler)

​

StringImpl 1020 KB

<--- AtomicString::AtomicString()

<--- ScriptResource::script()

*

*

More detailed profiling

• Retaining relationships that cross allocator boundaries
• Blink retains a lot of memory in other allocators in the renderer process

​

HTMLLinkElement::m_resource => locked discardable memory (620 KB)

FontCustomPlatformData::m_typeface => Skia (700 KB)

*

*

Q4/Q1 Roadmap

• Add more profiling information to memory-infra
• Per-object-type profiler
• Allocation-site profiler
• Cross-allocator retaining relationships

​

• Add reproducible telemetry benchmarks and metrics with which developers can keep track of their reduction efforts

*

*

Understanding

Scope

• Scope:
• Understand the breakdown of renderer’s memory

​

• The following slides are focusing on memory only inside Blink, but our scope is to understand and reduce renderer’s memory (especially renderer’s memory retained by Blink)

*

*

Scope

• 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

​

• We’re now focusing on short-lived apps because short-lived apps would be more important in mobile devices, but long-lived apps are on our radar too

*

*

Break down the memory into pieces

• Break down renderer’s memory
• Renderer = V8 + PartitionAlloc + Oilpan + Skia + …

​

• Break down the PartitionAlloc’s memory
• PartitionAlloc = Buffer + FastMalloc + Node + Layout

​

• Break down each partition into per-object memory
• Buffer = StringImpl + Vector + HashTable + …
• FastMalloc = SharedBuffer + ...

*

*

Break down of renderer’s memory

*

*

Break down of renderer’s memory

• In common cases V8 is the largest consumer, but in these pages Blink is the largest consumer (20 - 40%)
• because the page set is chosen that way (i.e., they are key 10 pages where Blink’s reduction is a key)

​

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

*

*

Break down of Blink’s memory

• 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
• StringImpls, Vectors, HashTables, ArrayBuffers etc

​

• The second largest consumer is the FastMalloc partition
• SharedBuffers, all DOM objects except for Nodes and LayoutObjects

​

• 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
• We confirmed that more than 90% of the large StringImpls are JavaScript source code

​

• The second largest consumer is Vectors and HashTables
• We confirmed that 25% of the Vectors are consumed by the unused region
• We confirmed that 70% of the HashTables are consumed by the unused region of small HashTables

*

*

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) won’t contribute to reducing Blink’s memory

*

*

Summary

• The largest consumers inside Blink are:
• StringImpls
• SharedBuffers
• Vectors + HashTables

​

• BTW, how much memory is consumed by Vectors and HashTables as absolute values?
• Only < 1 MB... (even in the Blink-heavy pages)
• It’s not worth reducing...

*

*

What does it mean?

• Inside Blink, the only objects we should really reduce would be StringImpls and SharedBuffers

​

• Reducing other objects won’t contribute to reducing renderer’s memory

*

*

What does it mean?

• After reducing StringImpls and SharedBuffers, we should look at outside Blink, not inside Blink
• “Outside Blink” consumes 60 - 80% (even in the Blink-heavy pages)
• “Outside Blink” doesn’t mean that Blink is not related
• Blink retains a bunch of memory in Discardable, Skia, CC etc

​

• Remember that our goal is to reduce renderer’s memory

*

*

What we have learned

• Memory reduction based on a “guess” is NOT likely to contribute to a meaningful reduction
• Reducing sizeof(DOM object) won’t have an impact
• We experimented with discarding various Blink caches each TL listed in this spreadsheet, but most of them didn’t have an impact

*

*

What we have learned

• It is important to drive the reduction efforts more tactically
• Understand the breakdown
• Identify key problem areas (sweet spots)
• Reduce the memory at a pinpoint

*

*

What we have learned

• It is really hard to collect consistent and reproducible results
• It is a substantial amount of work to confirm the reasonableness of various memory metrics
• Example:
• Render’s private memory >> sum(memory usage of each allocator)
• Where does the dark matter come from…?
• Various “size” notions
• resident, effective, active, committed...

*

*

Q4/Q1 roadmap

• Get more understanding on outside Blink
• Understand the real world
• UMAs
• Deep reports
• OOM
• Identify X projects that would have the biggest impact
• Profile long-running apps

*

*

Reducing

Strategy

• Our strategy is:
• Provide good tooling and understanding
• Brainstorm ideas for reduction
• And enable more teams to get involved in the reduction (instead of only the memory team working on the reduction)
• That way we can move faster

*

*

On-going reduction projects

• MemoryPurgeController (⇒ Memory team)
• CompressableString (⇒ Memory team)
• More aggressive Resource pruning (⇒ Loading team)
• Making V8 ⇔ Blink cycles collectable (⇒ V8 team)

*

*

MemoryPurgeController

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

class MemoryPurgeController {

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

for (auto& client : m_clients)

client->purgeMemory(...);

}

HashSet<MemoryPurgeClient*> m_clients;

};

class MemoryCache : public MemoryPurgeClient {

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

};

*

*

MemoryPurgeController

• When does MemoryPurgeController dispatch the purgeMemory()?
• After 10 seconds after a tab goes inactive
• When Blink receives MemoryPressureListener’s notifications

*

*

MemoryPurgeController

• What should the purgeMemory() do?
• Discard discardable caches in Blink

​

• Even though the purgeMemory() is dispatched against only inactive tabs & memory-pressure situations, we must be careful about its performance impact

*

*

CompressableString

• The largest consumer of PartitionAlloc is large Strings

​

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

*

*

CompressableString

• We confirmed that if we gzip large Strings, 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 of Resources is important

*

*

More aggressive Resource pruning

• Actually, memory reduction of Resources is more important than the data implies, because Resources also retain memory in Discardable and Skia
• Some Resources use a locked memory in Discardable
• 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

• Goals:
• Don’t keep alive ResourcePtrs longer than needed
• Discard various caches retained by Resources (unless it regresses performance)
• Visualize the retaining relationships in memory-infra

*

*

Making V8 ⇔ Blink cycles collectable

• In common cases, V8 is the largest consumer 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

• In general, 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

• Various reduction projects are going on:
• MemoryPurgeController
• CompressableString (for StringImpls)
• More aggressive Resource pruning (for SharedBuffers)
• Making V8 ⇔ Blink cycles collectable

​

• As we identify more key problem areas, we’ll work with teams who own the area and brainstorm ideas for reduction

*

*

Q4/Q1 roadmap

• Establish the following development flow:
• Provide good tooling
• Identify key problem areas
• Work with teams who own the area and brainstorm reduction ideas
• Enable the teams to set memory-reduction OKRs and work on the reduction

*

*

Conclusions

Scope

​

​

​

• Understand and reduce renderer’s memory

*

*

Current understanding

• In Blink-heavy pages, Blink can be the largest consumer (20 - 40%)
• StringImpls
• SharedBuffers
• Vectors and HashTables

​

• After reducing StringImpls and SharedBuffers, we should look at outside Blink (some of them are retained by Blink)

*

*

Strategy

• Tooling
• Provide consistent data in memory-infra
• Provide reproducible telemetry benchmarks and metrics
• Understanding
• Identify sweet spots
• Reducing
• Brainstorm ideas
• Enable more teams to get involved

*

*

Strategy

• Our goal is to establish a development flow that enables each team to set memory-reduction OKRs and get involved in the reduction
• Instead of only the memory team working on the reduction :)

​

• Empowering TRIM for that direction!

*

*