Make task manager memory data more efficient and meaningful.

base/process/private_working_set_snapshot_win_unittest.cc

+// Copyright (c) 2012 The Chromium Authors. All rights reserved.

[ncarter (slow), 2015/06/26 21:46:16]

2015, no (c)

[brucedawson, 2015/06/27 00:13:06]

Done.

+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "base/process/private_working_set_snapshot.h"
+
+#include "base/win/windows_version.h"
+#include "testing/gtest/include/gtest/gtest.h"
+
+typedef testing::Test PrivateWorkingSetSnapshotWinTest;

[ncarter (slow), 2015/06/26 21:46:16]

Apparently we're supposed to prefer C++11 aliases now instead of typedefs.

using PrivateWorkingSetSnapshotWinTest = testing::Test;

https://chromium-cpp.appspot.com/#whitelist_lang_list

[brucedawson, 2015/06/27 00:13:06]

Done.

+
+TEST_F(PrivateWorkingSetSnapshotWinTest, FindPidSelfTest) {
+  // The Pdh APIs are supported on Windows XP, but the "Working Set - Private"
+  // counter that PrivateWorkingSetSnapshot depends on is not defined until
+  // Windows Vista. Early-out to avoid test failure.
+  if (base::win::GetVersion() < base::win::VERSION_VISTA)
+    return;
+
+  // Sample this process.
+  base::ProcessId pid = base::GetCurrentProcId();
+
+  base::PrivateWorkingSetSnapshot private_ws_snapshot;
+
+  private_ws_snapshot.AddToMonitorList("base_unittests");
+  private_ws_snapshot.Sample();
+
+  size_t private_ws = private_ws_snapshot.GetPrivateWorkingSet(pid);
+  // Private working set is difficult to predict but should be at least several
+  // MB. Initial tests show a value of ~4 MB to 25 MB depending on how many
+  // tests and processes are used. Anomalously small or large values would
+  // warrant investigation.
+  EXPECT_GT(private_ws, 2000000u);
+  // Check that the WS is less than 500 MB. This is set very high to reduce the
+  // change that unrelated changes could ever make this fail. This mostly just

[ncarter (slow), 2015/06/26 21:46:16]

change->chance

[brucedawson, 2015/06/27 00:13:05]

Done.

+  // checks against some uncaught error that might return 0xFFFFFFFF.

[ncarter (slow), 2015/06/26 21:46:16]

There are two things to worry about here. One is potential failures on the
drmemory and similar memory-instrumented bots where the heap can be bloated by
some large constant factor. Another is the fact that base_unittests don't spawn
a new process for every test, so we may be affected by previous tests.

My hunch is that if this fails in practice it will be a result of the previous
two issues occurring. Given that it's base_unittests, and not the whole browser,
we might just get lucky. It's fine to just deal with them as they occur.

[brucedawson, 2015/06/27 00:13:06]

Done.

+  EXPECT_LT(private_ws, 500000000u);

[ncarter (slow), 2015/06/26 21:46:16]

In a test similar to this (of code that reported memory usage), I've seen an
approach where you create a memory allocation of a large size N, touch every
page, after which point you could then do the following test expectations:

size_t private_ws2 = private_ws_snapshot.GetPrivateWorkingSet(pid);
EXPECT_EQ(private_ws, private_ws2) << "GetPrivateWorkingSet should be consistent
until the next call to Sample()";
private_ws_snapshot.Sample();
size_t private_ws3 = private_ws_snapshot.GetPrivateWorkingSet(pid);
EXPECT_GT(private_ws3, private_ws2 + N/2) << "GetPrivateWorkingSet should
increase as we allocate more memory";

[brucedawson, 2015/06/27 00:13:06]

Sounds good. Done.

+}