Cross-Component Garbage Collection

Embedding a modern language runtime as a component in a larger software system is popular these days. Communication between these systems often requires keeping references to each others' objects. In this paper we present and discuss the problem of cross-component memory management where reference cycles across component boundaries may lead to memory leaks and premature reclamation of objects may lead to dangling cross-component references. We provide a generic algorithm for effective, efficient, and safe garbage collection over component boundaries, which we call cross-component tracing. We designed and implemented cross-component tracing in the Chrome web browser where the JavaScript virtual machine V8 is embedded into the rendering engine Blink. Cross-component tracing from V8's JavaScript heap to Blink's C++ heap improves garbage collection latency and eliminates long-standing memory leaks for real websites in Chrome. We show how cross-component tracing can help web developers to reason about reachability and retainment of objects spanning both V8 and Blink components based on Chrome's heap snapshot memory tool. Cross-component tracing was enabled by default for all websites in Chrome version 57 and is also deployed in other widely used software systems such as Opera, Cobalt, and Electron.

Transcript

1. Cross-Component Garbage Collection Ulan Degenbaev十, Jochen Eisinger十, Kentaro Hara卄, Marcel Hlopko十, Michael Lippautz十, Hannes Payer十 十Google, Germany 卄Google, Japan
2. Contributions • Discussion of the cross-component memory management problem • Generic algorithm for integration with trace-based garbage collection called cross-component tracing (CCT) • Implementation (artifact) based on Chrome’s V8 JavaScript virtual machine and the Blink renderer that improves performance over the current implementation called object grouping • Description of how CCT increases tooling capabilities
3. Background: Browsers other other V8 (JS VM) Blink (Renderer) Browser Chrome
4. Background: Browsers V8 (JS VM) Blink (Renderer)
5. Problem • Software split in components with hard boundaries • Ways to compose arbitrary object graphs across components • No static ownership of memory • Potentially differently managed environments A B object cross-component reference component boundary, e.g. API
6. Problem • Software split in components with hard boundaries • Ways to compose arbitrary object graphs across components • No static ownership of memory • Potentially differently managed environments Unknown references create roots into environment A B root
7. Problem • Software split in components with hard boundaries • Ways to compose arbitrary object graphs across components • No static ownership of memory • Potentially differently managed environments Unknown references create roots into environment A B root
8. Problem • Software split in components with hard boundaries • Ways to compose arbitrary object graphs across components • No static ownership of memory • Potentially differently managed environments Unknown references create roots into environment A B c.f. reference counting cycles
9. Effective, efficient, and safe garbage collection across component boundaries
10. Approach Break cycle by providing one component with the ability to reason about liveness across components A B
11. Approach Break cycle by providing one component with the ability to reason about liveness across components A B root B’s point of view
12. Approach Break cycle by providing one component with the ability to reason about liveness across components A B A’s point of view cross-component reference treated as regular references
13. Approach Break cycle by providing one component with the ability to reason about liveness across components A B A’s point of view
14. Approach Break cycle by providing one component with the ability to reason about liveness across components A B B’s point of view
15. Approach Break cycle by providing one component with the ability to reason about liveness across components A B
16. Back to the Web • DOM: Document Object Model • JavaScript: Language of the web • … and much more V8 (JS VM) Blink (Renderer)
17. The Web DOM: Document Object Model • Cross-platform language-independent representation of HTML • Web Interface Definition Language (IDL) • Traditionally encoded as objects in the rendering engine (e.g. Blink) Photo: Birger Eriksson / CC-BY-SA-3.0
18. The Web JavaScript: Language of the web • Used to interact with the DOM • Untrusted code executed in an isolated environment, the virtual machine of a browser <script> function createDiv() { let newDiv = document.createElement("div"); document.body.appendChild(newDiv); } document.addEventListener( "DOMContentLoaded", createDiv); </script>
19. V8 and Blink V8 • JavaScript: Custom object layout • Generational mark-sweep-compact garbage collector ◦ Mostly concurrent and parallel with incremental fallbacks Blink • DOM: C++ objects • Mark-sweep garbage collector ◦ Incremental marking and sweeping and “some” compaction Implementation details in the paper
20. V8 and Blink Different memory layouts and object models (JS vs C++) and separate garbage collectors
21. V8 and Blink • JavaScript ⇔ DOM • Objects come in halves • Reference each other <script> document; </script> document blink::HTMLDocument V8 Blink
22. Example <!DOCTYPE html> <head><script> function createDiv() { let newDiv = document.createElement("div"); document.body .appendChild(newDiv); } document.addEventListener( "DOMContentLoaded", createDiv); </script></head> <body> <span></span> </body> </html> V8 Blink
23. Example <!DOCTYPE html> <head><script> function createDiv() { let newDiv = document.createElement("div"); document.body .appendChild(newDiv); } document.addEventListener( "DOMContentLoaded", createDiv); </script></head> <body> <span></span> </body> </html> V8 Blink document blink::HTMLDocument Hashmap "DOMContentLoaded” blink::EventListener blink::HTMLBodyElement blink::HTMLSpanElement blink::HTMLDivElement Code (createDiv) body newDiv closure "div” Fine print: Missing out on a lot of details here.
24. Simplified setup V8 Blink c’ c • V8 garbage collections used to break cycles • Allow V8 to see (parts of) Blink’s (or other embedders) object graphs b’ b a’ a d’ d
25. Object Grouping Based on the observations • Javascript objects belong to a given DOM tree • DOM is (mostly) fully connected: Each node keeps the whole tree alive V8 Blink c’ c b’ b a’ a d’ d
26. Object Grouping Approximation: Objects are alive as long as a single object in the corresponding DOM tree is live V8 Blink c’ c b’ b a’ a d’ d DOM tree 1 DOM tree 1 DOM tree 1 DOM tree 2
27. Object Grouping Approximation: Objects are alive as long as a single object in the corresponding DOM tree is live Properties + Implementation only needs FindDOMTree(object) - Requires recomputing after mutator invocation - Requires considering “dead” DOM trees V8 Blink c’ c b’ b a’ a d’ d DOM tree 1 DOM tree 1 DOM tree 1 DOM tree 2
28. Effective, efficient, and safe garbage collection across component boundaries
29. Cross-Component Tracing Extend the garbage collectors’ capabilities to allow tracing remote components V8 Blink c’ c b’ b a’ a d’ d
30. Cross-Component Tracing Extend the garbage collectors’ capabilities to allow tracing remote components V8 Blink c’ c b’ b a’ a d’ d
31. Cross-Component Tracing Extend the garbage collectors’ capabilities to allow tracing remote components Properties: + Standard GC literature applies (incremental, concurrent) + Debuggability + Performance/memory - Implementation requires understanding of object structure (description of object body) V8 Blink c’ c b’ b a’ a d’ d
32. Effective, efficient, and safe garbage collection across component boundaries
33. Results: Debuggability Example (see paper) retaining path of objects involving JavaScript and DOM, e.g. for diagnosing leaks W indow (JS) H TM LDocum ent (JS) H TM LDocum ent (DOM ) H TM LH tm lElem ent (DOM ) H TM LBodyElem ent (DOM ) H TM LDivElem ent (DOM ) H TM LElem ent (DOM ) EventListener (DOM ) Environm ent (JS) Leak (JS) W indow (JS) H TM LDocum ent (JS) H TM LDocum ent (DOM ) H TM LElem ent (DOM ) Environm ent (JS) Leak (JS) Cross-component tracing Object grouping … JS … C++
34. Results: Debuggability in DevTools Object grouping Cross-component tracing Chrome Canary (72.0.3604.0) Chrome Stable M57
35. Experimental evaluation • Chrome version M57 (Feb 2017) • Chrome’s Catapult performance benchmarking framework to measure on real webpages • Configurations: ◦ Baseline: Incremental marking with incremental object grouping (OGI) ▪ re-computing groups when close to end of marking ◦ Incremental marking with cross-component tracing (CCTI) • Metrics: ◦ Throughput: Total garbage collection time ◦ Latency: garbage collection pause for finalization, mutator utilization ◦ Memory: Sampled memory usage • Methodology: ◦ 10 runs per webpage, per configuration ◦ Compare configurations using Wilcoxon rank sum test ◦ Results shown with 95% confidence intervals
36. Results • Finalization pause latency: ◦ Improved 6/16 ◦ Regressed: 2/16 ◦ Not significant: 8/16 • Regressions caused by heuristics and scheduling changes: Entering atomic pause too early Finalization pause time: CCTI compared to OGI
37. Results: See paper • Throughput ◦ No significant changes on benchmarks (1 small regression) • Latency MMU ◦ Improvements in the order of single-digit percentages across the board ◦ Expected as main garbage collection pause dominates • Memory ◦ No significant changes on benchmarks ◦ Expected as object grouping is on average acceptable ◦ Leaks caused by object grouping (due to it’s non-ideal approximation of liveness) gone in the wild
38. Takeaways Cross-Component Tracing enables garbage collection that is effective, efficient, and safe. Compared to Object Grouping it... • Reduces leaks caused by bad approximations • Improves latency of V8’s garbage collector • Improves debuggability by providing exact retaining paths
39. Future work Cross-Component Tracing enables garbage collection that is effective, efficient, and safe. Observations ◦ V8 garbage collection is required to break cycles ◦ Blink garbage collections should be scheduled after V8 ◦ Scheduling two different garbage collectors is fragile (bag of heuristics) ◦ Set of live objects on the Blink heap is processed twice by both collectors Unified heap garbage collections: Perform a single garbage collection across multiple components Efficiency is relative — can we do better?
40. Our group is hiring! Reach out to us if you are interested V8 Blink c’ c b’ b a’ a d’ d Thank you / Q&A mlippautz@google.com https://research.google.com/pubs/MichaelLippautz.html Cross-Component Tracing Extend the garbage collectors’ capabilities to allow tracing remote components