[Memory] Add system_memory_stats_recorder_win.cc

tools/metrics/histograms/histograms.xml

Index: tools/metrics/histograms/histograms.xml
diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml
index 9af6b4ad2287957aa5895db90a742ed8393e6c4b..062a53e2fd789a72f13b69a34c61b9b2d9484e0c 100644
--- a/tools/metrics/histograms/histograms.xml
+++ b/tools/metrics/histograms/histograms.xml
@@ -16679,6 +16679,143 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
   </summary>
 </histogram>
 
+<histogram name="Memory.OOMKill.Extensions.Win.AvailPageFile" units="MB">

[rkaplow, 2015/06/30 18:21:48]

i wonder if it makes sense to change these to 
Memory.OOMKill.Win.*.Extension
Memory.OOMKill.Win.*.Browser (or nonextension, or something)


You can then use the suffix notation (see docs near top of file) to make this
much more compact, but using Extension and Browser/nonextension as suffixed.


Another possibility is to use the
AvailPhys / AvailVirtual ... as the suffixes. That might even make more sense
since then it works for the Discard histogram. This is an interesting situation
with a MxN setup with suffixes, I've not seen that.

[Ilya Sherman, 2015/07/01 02:25:14]

MxN suffixes already exist in the file -- they're just not obvious. 
histogram_suffixes can list affected histogram names that come from a different
histogram_suffixes element.  There's some limit to the amount of nesting
allowed, but it's at least two levels.

[Ilya Sherman, 2015/07/01 02:28:59]

I do agree, FWIW, that it probably makes sense to move "Win" to precede
"Extensions" -- I'd make the order "Memory.OOMKill.Win.Extensions.AvailPhys". 
IMO this would do the best job of grouping things together based on what's most
directly comparable.  Alternately, if these histograms *could* be implemented on
non-Windows machines -- i.e. if the memory models are compatible -- then I'd
just omit "Win" entirely.  It would be clear from the dashboard that these are
only implemented on Windows.

[Georges Khalil, 2015/07/06 17:47:32]

Memory models are not compatible, which is why we have platform specific
histograms.

Changed naming to use suffixes.

+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the maximum amount of memory the current
+    process can commit, after a renderer was killed by oom-killer. This value is
+    equal to or smaller than the system-wide available commit value.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Extensions.Win.AvailPhys" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the amount of physical memory currently
+    available after a renderer was killed by oom-killer. This is the amount of
+    physical memory that can be immediately reused without having to write its
+    contents to disk first. It is the sum of the size of the standby, free, and
+    zero lists.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Extensions.Win.AvailVirtual" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the amount of unreserved and uncommitted
+    memory currently in the user-mode portion of the virtual address space of
+    the calling process, after a renderer was killed by oom-killer.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Extensions.Win.MemoryLoad" units="percent">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the approximate percentage of physical
+    memory that was in use after a renderer was killed by oom-killer (0
+    indicates no memory use and 100 indicates full memory use).
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Extensions.Win.TotalPageFile" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the current committed memory limit for
+    the system or the current process, whichever is smaller, after a renderer
+    was killed by oom-killer.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Extensions.Win.TotalPhys" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the amount of actual physical memory
+    after a renderer was killed by oom-killer.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Extensions.Win.TotalVirtual" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the size of the user-mode portion of the
+    virtual address space of the calling process, at the time a tab was after a
+    renderer was killed by oom-killer. This value depends on the type of
+    process, the type of processor, and the configuration of the operating
+    system. For example, this value is approximately 2 GB for most 32-bit
+    processes on an x86 processor and approximately 3 GB for 32-bit processes
+    that are large address aware running on a system with 4-gigabyte tuning
+    enabled.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Win.AvailPageFile" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the maximum amount of memory the current
+    process can commit, after a renderer was killed by oom-killer. This value is
+    equal to or smaller than the system-wide available commit value.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Win.AvailPhys" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the amount of physical memory currently
+    available after a renderer was killed by oom-killer. This is the amount of
+    physical memory that can be immediately reused without having to write its
+    contents to disk first. It is the sum of the size of the standby, free, and
+    zero lists.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Win.AvailVirtual" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the amount of unreserved and uncommitted
+    memory currently in the user-mode portion of the virtual address space of
+    the calling process, after a renderer was killed by oom-killer.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Win.MemoryLoad" units="percent">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the approximate percentage of physical
+    memory that was in use after a renderer was killed by oom-killer (0
+    indicates no memory use and 100 indicates full memory use).
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Win.TotalPageFile" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the current committed memory limit for
+    the system or the current process, whichever is smaller, after a renderer
+    was killed by oom-killer.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Win.TotalPhys" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the amount of actual physical memory
+    after a renderer was killed by oom-killer.
+  </summary>
+</histogram>
+
+<histogram name="Memory.OOMKill.Win.TotalVirtual" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the size of the user-mode portion of the
+    virtual address space of the calling process, after a renderer was killed by
+    oom-killer. This value depends on the type of process, the type of
+    processor, and the configuration of the operating system. For example, this
+    value is approximately 2 GB for most 32-bit processes on an x86 processor
+    and approximately 3 GB for 32-bit processes that are large address aware
+    running on a system with 4-gigabyte tuning enabled.
+  </summary>
+</histogram>
+
 <histogram name="Memory.OtherProcessCount">
   <owner>hajimehoshi@chromium.org</owner>
   <owner>kenjibaheux@google.com</owner>
@@ -44576,6 +44713,74 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.
   </summary>
 </histogram>
 
+<histogram name="Tabs.Discard.Win.AvailPageFile" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the maximum amount of memory the current
+    process can commit, at the time a tab was discarded. This value is equal to
+    or smaller than the system-wide available commit value.
+  </summary>
+</histogram>
+
+<histogram name="Tabs.Discard.Win.AvailPhys" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the amount of physical memory currently
+    available at the time a tab was discarded. This is the amount of physical
+    memory that can be immediately reused without having to write its contents
+    to disk first. It is the sum of the size of the standby, free, and zero
+    lists.
+  </summary>
+</histogram>
+
+<histogram name="Tabs.Discard.Win.AvailVirtual" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the amount of unreserved and uncommitted
+    memory currently in the user-mode portion of the virtual address space of
+    the calling process, at the time a tab was discarded.
+  </summary>
+</histogram>
+
+<histogram name="Tabs.Discard.Win.MemoryLoad" units="percent">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the approximate percentage of physical
+    memory that was in use at the time a tab was discarded (0 indicates no
+    memory use and 100 indicates full memory use).
+  </summary>
+</histogram>
+
+<histogram name="Tabs.Discard.Win.TotalPageFile" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the current committed memory limit for
+    the system or the current process, whichever is smaller, at the time a tab
+    was discarded.
+  </summary>
+</histogram>
+
+<histogram name="Tabs.Discard.Win.TotalPhys" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the amount of actual physical memory at
+    the time a tab was discarded.
+  </summary>
+</histogram>
+
+<histogram name="Tabs.Discard.Win.TotalVirtual" units="MB">
+  <owner>georgseak@chromium.org</owner>
+  <summary>
+    Windows-only metric that represents the size of the user-mode portion of the
+    virtual address space of the calling process, at the time a tab was
+    discarded. This value depends on the type of process, the type of processor,
+    and the configuration of the operating system. For example, this value is
+    approximately 2 GB for most 32-bit processes on an x86 processor and
+    approximately 3 GB for 32-bit processes that are large address aware running
+    on a system with 4-gigabyte tuning enabled.
+  </summary>
+</histogram>
+
 <histogram name="Tabs.ForegroundTabAgeAtStartup" units="minutes">
   <owner>lliabraa@chromium.org</owner>
   <summary>