Untangling the web: Memory management in Chrome’s web platform implementation
summary
Chrome implements a cross-component tracing GC that coordinates Blink’s C++ collector and V8’s JavaScript collector, adds tooling to inspect mixed C++/JS graphs, and ships incremental changes on master. A new concurrent marker uses a snapshotting for unsafe shape changes algorithm (avoiding heavyweight layout locks), tested on Chrome M72 with the record‑replay benchmark suite; snapshotting yields the best total marking time while multiple designs show roughly equivalent main‑thread responsiveness within the 16 ms frame budget.
AI-written summary · about
chapters (19)
- 0:00Intro
- 2:17What we work on
- 3:00Rule of thumb: Ship incrementally where possible
- 5:35Talk covers most recent work
- 6:04Chrome architecture
- 7:49Interlude: Rendering 101
- 11:04Changing state
- 21:11Cross-component garbage collection (CC GC)
- 22:14Interlude: Tri-color marking
- 26:17V8 and Blink: Garbage collection architecture
- 31:07Runtime optimization: Double unboxing
- 33:35Double unboxing changes the shape of an object
- 34:02Traditional marking round
- 35:31Safe and unsafe shape changes
- 37:35Wait-free snapshotting algorithm
- 39:18Evaluation: Marking time on main thread
- 40:39Evaluation: Total marking time (all threads)
- 41:18Concurrent marking of shape-changing objects
- 42:05Final thoughts
related talks
05mIn hope for better memory tools
31mJavaScript memory management: Visual Guide
23mWarp Speed Memory Management
22mThe Hitchhiker's Guide to All Things Memory in JS
21mMemory: Don't Forget to Take Out the Garbage
30mMemory Don't Forget To Take Out The Garbage
53mPlugging Memory Leaks With The Chrome Dev Tools
35mMemory Chronicles: Manage, Trace and Fix Memory Leaks