The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/26c1f21886635acf097ee6015157f32969df5f77

commit 26c1f21886635acf097ee6015157f32969df5f77
Author: Lalit Maganti <lalitm@chromium.org>
Date: Thu Oct 19 11:45:48 2017

memory-infra: plumb whether to append to trace or not into CoordinatorImpl

Currently the RequestGlobalDump has an ambiguous dual semantic: return results
or add to the trace. For historical reasons both semantics have been collapsed 
in the same function, but this is now getting too hairy, making the codebase hard
to reason about, and caused some bugs.

Splitting the functions names as they clearly achieve two different functions
with different outcomes, specifically:
When adding the dump to the trace, clients don't care about the returned
object (which also happens to be empty). Likewise when returning the dump
(e.g. for SUMMARY_ONLY) the clients don't care about the dump_guid.

Bug:  775039 
Change-Id: Ia0861bcd20775802813a35f5a138fa022521f416
Reviewed-on: https://chromium-review.googlesource.com/721540
Commit-Queue: Lalit Maganti <lalitm@chromium.org>
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510055}
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/chrome/browser/metrics/process_memory_metrics_emitter.cc
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/chrome/browser/metrics/process_memory_metrics_emitter.h
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/chrome/browser/metrics/process_memory_metrics_emitter_browsertest.cc
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/chrome/browser/metrics/process_memory_metrics_emitter_unittest.cc
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/content/browser/tracing/background_memory_tracing_observer.cc
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/content/browser/tracing/memory_tracing_browsertest.cc
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/services/resource_coordinator/memory_instrumentation/coordinator_impl.cc
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/services/resource_coordinator/memory_instrumentation/coordinator_impl.h
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/services/resource_coordinator/memory_instrumentation/coordinator_impl_unittest.cc
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/services/resource_coordinator/public/cpp/memory_instrumentation/client_process_impl.cc
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/services/resource_coordinator/public/cpp/memory_instrumentation/memory_instrumentation.cc
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/services/resource_coordinator/public/cpp/memory_instrumentation/memory_instrumentation.h
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/services/resource_coordinator/public/cpp/memory_instrumentation/tracing_integration_unittest.cc
[modify] https://crrev.com/26c1f21886635acf097ee6015157f32969df5f77/services/resource_coordinator/public/interfaces/memory_instrumentation/memory_instrumentation.mojom

Complete with the above CL!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6547c90cb4f8b49cd11bdb36ee2ed911d933d21b

commit 6547c90cb4f8b49cd11bdb36ee2ed911d933d21b
Author: Lalit Maganti <lalitm@chromium.org>
Date: Fri Oct 20 17:18:34 2017

memory-infra: split CoordinatorImpl into two classes

CoordinatorImpl was becoming an unwieldy class with a lot of
functionality tied up into a single file and risked becoming a god
class. In particular, it performed the following functions:
1. Queued requests and handled threading hops to do with maintaining the
queue etc.
2. Dispatched requests to process-local MDMs and then collated the
responses once everything responded/failed.
3. Listened to Mojo callbacks to track which clients have
registered/unregistered.

By examining the code, one sees that number 2 is in some ways orthogonal
to the work done for 1 and 3. In particular, big chunks of code deal
with only a single request and how it should be dispatched or how the
responses should be collated and returned.

This CL splits the functions described by 2 into a new class. It also
extracts the concept of a queued request into a namespaced class to
allow for sharing between CoordinatorImpl and the new class.

This vastly reduces the apparent complexity of CoordinatorImpl and
solidfies its purpose as a class handling the queueing of requests with
the new class handling single requests.

Bug:  775039 
Change-Id: I313695782ae73619a15b4acad40f657177467c3d
Reviewed-on: https://chromium-review.googlesource.com/728060
Reviewed-by: Hector Dearman <hjd@chromium.org>
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Commit-Queue: Lalit Maganti <lalitm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510474}
[modify] https://crrev.com/6547c90cb4f8b49cd11bdb36ee2ed911d933d21b/services/resource_coordinator/BUILD.gn
[modify] https://crrev.com/6547c90cb4f8b49cd11bdb36ee2ed911d933d21b/services/resource_coordinator/memory_instrumentation/coordinator_impl.cc
[modify] https://crrev.com/6547c90cb4f8b49cd11bdb36ee2ed911d933d21b/services/resource_coordinator/memory_instrumentation/coordinator_impl.h
[add] https://crrev.com/6547c90cb4f8b49cd11bdb36ee2ed911d933d21b/services/resource_coordinator/memory_instrumentation/queued_request.cc
[add] https://crrev.com/6547c90cb4f8b49cd11bdb36ee2ed911d933d21b/services/resource_coordinator/memory_instrumentation/queued_request.h
[add] https://crrev.com/6547c90cb4f8b49cd11bdb36ee2ed911d933d21b/services/resource_coordinator/memory_instrumentation/queued_request_dispatcher.cc
[add] https://crrev.com/6547c90cb4f8b49cd11bdb36ee2ed911d933d21b/services/resource_coordinator/memory_instrumentation/queued_request_dispatcher.h