Add new wired memory metric to memory-infra dumps.

base/process/process_metrics_unittest.cc

Index: base/process/process_metrics_unittest.cc
diff --git a/base/process/process_metrics_unittest.cc b/base/process/process_metrics_unittest.cc
index b11a26b24ba7cfd5417c519dff06257d5b3bb17b..fe83b49957e4deae45a025176dd8d2e0b8affb2b 100644
--- a/base/process/process_metrics_unittest.cc
+++ b/base/process/process_metrics_unittest.cc
@@ -24,6 +24,12 @@
 #include "testing/gtest/include/gtest/gtest.h"
 #include "testing/multiprocess_func_list.h"
 
+#if defined(OS_MACOSX)
+#include <sys/mman.h>
+
+#include "base/memory/free_deleter.h"
+#endif
+
 namespace base {
 namespace debug {
 
@@ -53,6 +59,37 @@ class SystemMetricsTest : public testing::Test {
 
 /////////////////////////////////////////////////////////////////////////////
 
+#if defined(OS_MACOSX)
+TEST_F(SystemMetricsTest, WiredBytes) {
+  ProcessHandle handle = GetCurrentProcessHandle();
+  std::unique_ptr<ProcessMetrics> metrics(
+      ProcessMetrics::CreateProcessMetrics(handle, nullptr));
+
+  size_t initial_wired_bytes;
+  bool result =
+      metrics->GetMemoryBytes(nullptr, nullptr, nullptr, &initial_wired_bytes);
+  ASSERT_TRUE(result);
+
+  size_t size = 999 * PAGE_SIZE;
+  std::unique_ptr<char, base::FreeDeleter> memory(

[Primiano Tucci (use gerrit), 2017/03/28 20:32:54]

just std::unique_ptr<char[])(new char[size)); ?

[erikchen, 2017/03/30 00:03:14]

Done.

+      static_cast<char*>(malloc(size)));
+  int r = mlock(memory.get(), size);
+  ASSERT_EQ(r, 0);
+
+  size_t new_wired_bytes;
+  result = metrics->GetMemoryBytes(nullptr, nullptr, nullptr, &new_wired_bytes);
+  ASSERT_TRUE(result);
+  EXPECT_EQ(initial_wired_bytes + size, new_wired_bytes);
+
+  r = munlock(memory.get(), size);
+  ASSERT_EQ(r, 0);
+
+  result = metrics->GetMemoryBytes(nullptr, nullptr, nullptr, &new_wired_bytes);
+  ASSERT_TRUE(result);
+  EXPECT_EQ(initial_wired_bytes, new_wired_bytes);

[Primiano Tucci (use gerrit), 2017/03/28 20:32:54]

I got bitten in the past by this sort of tests. The thing that did bite me is
the fact that gtest might run other things on its own thread. Not sure how
likely is to end up mlocking memory from random (gtest) code.
In doubt, the sort of pattern that I used in the past was:
- Lock(X) with X somewhat big (say ~MBs)
- assert that locked >= X/2 (/2 to compensate for gtest unlocking something else
in the meantime)

[Mark Mentovai, 2017/03/28 20:56:11]

Is gtest really running its own threads? That’s surprising.

But yeah, you should deal with this, regardless of who’s starting the threads.
I’ve certainly seen trouble with other tests in the same process leaking threads
(or even not leaking them, just spinning up singleton threads that wind up not
quiescent), and a bunch of trouble with threads started by the OS (specifically
on Android, but also specifically on macOS, and also specifically on Windows…so
everywhere).

[erikchen, 2017/03/30 00:03:14]

Done.

+}
+#endif  // defined(OS_MACOSX)
+
 #if defined(OS_LINUX) || defined(OS_ANDROID)
 TEST_F(SystemMetricsTest, IsValidDiskName) {
   std::string invalid_input1 = "";