Introduce MemoryCoordinatorProxy in base

base/memory/memory_coordinator_proxy.cc

Index: base/memory/memory_coordinator_proxy.cc
diff --git a/base/memory/memory_coordinator_proxy.cc b/base/memory/memory_coordinator_proxy.cc
new file mode 100644
index 0000000000000000000000000000000000000000..7e8527504102864bc63ca70631b8ca77699cb22b
--- /dev/null
+++ b/base/memory/memory_coordinator_proxy.cc
@@ -0,0 +1,30 @@
+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "base/memory/memory_coordinator_proxy.h"
+
+namespace base {
+
+MemoryCoordinatorProxy::MemoryCoordinatorProxy() {
+}
+
+MemoryCoordinatorProxy::~MemoryCoordinatorProxy() {
+}
+
+MemoryCoordinatorProxy* MemoryCoordinatorProxy::GetInstance() {
+  return Singleton<base::MemoryCoordinatorProxy>::get();
+}
+
+MemoryState MemoryCoordinatorProxy::GetCurrentMemoryState() const {
+  if (!callback_)
+    return MemoryState::NORMAL;

[haraken, 2016/10/24 09:01:15]

Is this an expected behavior?

I guess it's better to force all processes install the callback function, and
add DHECK(callback_).

[hajimehoshi, 2016/10/24 10:56:52]

Hmm, why we decided to use NORMAL as default is because the feature list might
not be initialized before a MemoryCoordinatorClient is created. This was needed
when the current memory state needed to be known at such client's constructor.
Now there are not actual such cases, but can we assume 
MemoryCoordinatorProxy::GetCurrentMemoryState is called AFTER the feature list
is initialized now?

[haraken, 2016/10/24 11:35:39]

I think the feature list should be initialized at the very beginning of the
browser/renderer execution. Otherwise, it will confuse many things. Is it not
true?

[bashi, 2016/10/24 23:35:57]

It's probably true, but I think it's better to return the default state (NORMAL)
when callback_ is not set. Here are some reasons:
- It's hard to make sure that all callsites wait for memory coordinator
initialization. We can't initialize MC until base::FeatureList must be
initialized, but some MemoryCoordinatorClients (e.g. clients in cc/) are
instanciated before base::FeatureList is initialized.
- In tests we may not install a callback. base/ should work without depending
other components.

+  return callback_.Run();
+}
+
+void MemoryCoordinatorProxy::SetGetCurrentMemoryStateCallback(
+    GetCurrentMemoryStateCallback callback) {
+  callback_ = callback;
+}
+
+}  // namespace base