Previously, the browser passed a "sender_id" to child processes during startup. The child process would then create a pair of pipes, and send one pipe to the profiling process, along with the "sender_id". This has several flaws: 1) It exposes the profiling process to renderers. 2) It requires the profiling process to trust the "sender_id" sent by the renderer. 3) It requires the renderer to create a PlatformChannelPair, which it cannot do on Windows because of the sandbox. 4) The "sender_id" eventually needs to be mapped back to an actual process.
In the new model: 1) Child processes expose a MemlogClient interface. 2) Each child process has an instance of a MemlogClient that listens for a "StartProfiling" request from the browser process. On receiving the request, it begins profiling and sends the data into the handle passed from StartProfiling. 3) The browser process observes creations of all child processes. When a new process is created, the browser process creates a PlatformChannelPair. It passes one pipe to the child via MemlogClient::StartProfiling, and the other to the profiling process via Memlog::AddSender. 4) The browser process also passes the pid of the process to the profiling process. This allows the chrome://memory-internals UI to trigger a dump of the appropriate process.
Minor changes include:
- Many lifetime semantic improvements. In all child processes, a single MemlogClient [owned by ChromeContentClient] is responsible for owning all profiling-relevant objects.
- In the browser process, the MemlogClient in ChromeContentClient does nothing. Instead, ChromeBrowserMainExtraPartsProfiling creates the singleton ProfilingProcessHost, which in turn owns a MemlogClient, which is responsible for all profiling in the process. Yes, this is a second instance of MemlogClient in the browser process.
- Removed all code from chrome/common/profiling/memlog_sender.h, which included some duplicate code for connecting to the profiling process, starting profiling in the current process, and a wacky global.
- Previously, the "--memlog" switch was not respected. Any binary compiled with enable_oop_heap_profiling would start the profiler. Now, the browser process only creates the ProfilingProcessHost if the "--memlog" switch has been set.
Bug: 751302, 751283 Change-Id: I84c570631ef999f76d3145fe1a9d4387f4d3147d Reviewed-on: https://chromium-review.googlesource.com/602526 Commit-Queue: Albert J. Wong
59d85ac Rework communication model for out-of-process heap profiling.
chrome/browser/chrome_content_browser_client.cc | 11 +-
.../chrome_content_gpu_manifest_overlay.json | 8 +-
.../chrome_content_renderer_manifest_overlay.json | 8 +-
.../chrome_content_utility_manifest_overlay.json | 1 +
chrome/browser/profiling_host/BUILD.gn | 2 +
.../chrome_browser_main_extra_parts_profiling.cc | 21 +++
.../chrome_browser_main_extra_parts_profiling.h | 26 +++
.../profiling_host/profiling_process_host.cc | 186 ++++++++++++++-------
.../profiling_host/profiling_process_host.h | 59 +++++--
chrome/browser/ui/webui/memory_internals_ui.cc | 40 +----
chrome/common/chrome_content_client.cc | 14 +-
chrome/common/chrome_content_client.h | 8 +-
chrome/common/chrome_switches.cc | 6 -
chrome/common/chrome_switches.h | 2 -
chrome/common/profiling/BUILD.gn | 8 +-
chrome/common/profiling/memlog.mojom | 15 +-
chrome/common/profiling/memlog_client.cc | 58 +++++++
chrome/common/profiling/memlog_client.h | 50 ++++++
chrome/common/profiling/memlog_client.mojom | 15 ++
chrome/common/profiling/memlog_sender.cc | 78 ---------
chrome/common/profiling/memlog_sender.h | 41 -----
chrome/profiling/memlog_connection_manager.cc | 47 +++---
chrome/profiling/memlog_connection_manager.h | 11 +-
chrome/profiling/memlog_impl.cc | 14 +-
chrome/profiling/memlog_impl.h | 5 +-
25 files changed, 419 insertions(+), 315 deletions(-)