Report utility process JS memory in task manager.

content/browser/process_resource_usage_impl.h

Index: content/browser/process_resource_usage_impl.h
diff --git a/content/browser/process_resource_usage_impl.h b/content/browser/process_resource_usage_impl.h
new file mode 100644
index 0000000000000000000000000000000000000000..890cf244c9f44ec875659b03468ca0c505351d6e
--- /dev/null
+++ b/content/browser/process_resource_usage_impl.h
@@ -0,0 +1,53 @@
+// Copyright 2015 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.
+
+#ifndef CONTENT_BROWSER_PROCESS_RESOURCE_USAGE_IMPL_H_
+#define CONTENT_BROWSER_PROCESS_RESOURCE_USAGE_IMPL_H_
+
+#include "base/basictypes.h"
+#include "base/memory/scoped_ptr.h"
+#include "base/memory/weak_ptr.h"
+#include "base/message_loop/message_loop_proxy.h"
+#include "base/synchronization/lock.h"
+#include "content/public/browser/process_resource_usage.h"
+#include "content/public/common/resource_usage_reporter.mojom.h"
+
+namespace content {
+

[ncarter (slow), 2015/05/01 21:16:52]

Could you add a class comment that tries to answers the following questions:
 - Who is this for
 - How do I get one
 - What does it do

[Anand Mistry (off Chromium), 2015/05/06 02:44:18]

Expanded the class comment for the public interface, which I think is more
appropriate than adding one here since this is just the implementation.

[ncarter (slow), 2015/05/07 20:12:43]

Makes sense, thank you.

+class CONTENT_EXPORT ProcessResourceUsageImpl : public ProcessResourceUsage {
+ public:
+  // Must be called from the same thread that created |service|.
+  explicit ProcessResourceUsageImpl(ResourceUsageReporterPtr service);
+
+  // ProcessResourceUsage implementation. May be called from any thread.
+  void Refresh() override;
+  bool ReportsV8MemoryStats() const override;
+  size_t GetV8MemoryAllocated() const override;
+  size_t GetV8MemoryUsed() const override;
+
+ private:
+  class Client;
+
+  ~ProcessResourceUsageImpl() override;
+
+  // Data refresh callback. Will be run on |mojo_message_loop_|.
+  void OnRefreshDone(ResourceUsageDataPtr data);
+
+  // Accessed on any thread.
+  mutable base::Lock lock_;

[ncarter (slow), 2015/05/01 21:16:52]

What would this look like if we used PostTask instead of Locks? Locks are
considered an anti-pattern in chrome ["We discourage locking and thread-safe
objects." http://dev.chromium.org/developers/design-documents/threading ] [
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/dR0XM1OFaeA/6CFFd...
] [
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/dR0XM1OFaeA/Y1zSW...
]

[Anand Mistry (off Chromium), 2015/05/06 02:44:18]

Done. It's cleaner, but requires some passing around since the Mojo connection
must be created on the IO thread.

+  ResourceUsageDataPtr stats_;
+
+  // Message loop the Mojo service is tied to. Mojo interfaces are
+  // thread-hostile and must always be accessed from the same thread.
+  scoped_refptr<base::MessageLoopProxy> mojo_message_loop_;

[ncarter (slow), 2015/05/01 21:16:52]

This is my first time looking at code that uses mojo. I'm actually a little
surprised that these messages are handled on the browser process IO thread and
written into a struct that is lock-protected -- I thought part of the promise of
mojo was to "bury the pipes," which I expected to mean something like: mojo
would take care of forwarding the IPC messages where they needed to be consumed,
e.g., the UI thread, and it wouldn't be users caller's responsibility to get
data to the IO thread?

Is it possible/conceivable to make this mojo interface live on the UI thread
(where the BrowserChildProcessObservers are?) Seems like that would eliminate
the need for the lock, and make it possible to notify observers (somehow) that
fresh stats had been collected?

[Anand Mistry (off Chromium), 2015/05/05 04:11:21]

Mojo hides all the IPC details, but it still exposes it's threading model. That
threading model is the reason for this design. No, you don't need to be on the
IO thread (or UI). But you do need to everything on the *same* thread,
regardless of that that thread is. This this case, the Mojo connection is
created on the IO thread for the utility process, so all the Mojo actions (IPC
calls, connection destruction, etc) have to happen on that same thread.

It is possible to move a Mojo connection to another thread. I'll look into how
complex it would be to use that.

+
+  // All methods must be posted to |mojo_message_loop_|.
+  base::WeakPtr<Client> client_;
+
+  DISALLOW_COPY_AND_ASSIGN(ProcessResourceUsageImpl);
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_PROCESS_RESOURCE_USAGE_IMPL_H_