author Nathan Froyd <froydnj@mozilla.com>
Tue, 15 Apr 2014 13:10:26 -0400
changeset 183767 c8f1a4f5ca4d
parent 178032 f33d8dee54da
permissions -rw-r--r--
Bug 993546 - Refactor malloc-wrapping memory reporter implementations. r=njn, a=abillings, ba=noidlchanges
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

#include "nsISupports.idl"

interface nsICancelableRunnable;
interface nsIDOMWindow;
interface nsIRunnable;
interface nsISimpleEnumerator;

 * Memory reporters measure Firefox's memory usage.  They are primarily used to
 * generate the about:memory page.  You should read
 * https://wiki.mozilla.org/Memory_Reporting before writing a memory
 * reporter.

[scriptable, function, uuid(3a61be3b-b93b-461a-a4f8-388214f558b1)]
interface nsIMemoryReporterCallback : nsISupports
   * The arguments to the callback are as follows.
   * |process|  The name of the process containing this reporter.  Each
   * reporter initially has "" in this field, indicating that it applies to the
   * current process.  (This is true even for reporters in a child process.)
   * When a reporter from a child process is copied into the main process, the
   * copy has its 'process' field set appropriately.
   * |path|  The path that this memory usage should be reported under.  Paths
   * are '/'-delimited, eg. "a/b/c".
   * Each reporter can be viewed as representing a leaf node in a tree.
   * Internal nodes of the tree don't have reporters.  So, for example, the
   * reporters "explicit/a/b", "explicit/a/c", "explicit/d/e", and
   * "explicit/d/f" define this tree:
   *   explicit
   *   |--a
   *   |  |--b [*]
   *   |  \--c [*]
   *   \--d
   *      |--e [*]
   *      \--f [*]
   * Nodes marked with a [*] have a reporter.  Notice that the internal
   * nodes are implicitly defined by the paths.
   * Nodes within a tree should not overlap measurements, otherwise the
   * parent node measurements will be double-counted.  So in the example
   * above, |b| should not count any allocations counted by |c|, and vice
   * versa.
   * All nodes within each tree must have the same units.
   * If you want to include a '/' not as a path separator, e.g. because the
   * path contains a URL, you need to convert each '/' in the URL to a '\'.
   * Consumers of the path will undo this change.  Any other '\' character
   * in a path will also be changed.  This is clumsy but hasn't caused any
   * problems so far.
   * The paths of all reporters form a set of trees.  Trees can be
   * "degenerate", i.e. contain a single entry with no '/'.
   * |kind|  There are three kinds of memory reporters.
   *  - HEAP: reporters measuring memory allocated by the heap allocator,
   *    e.g. by calling malloc, calloc, realloc, memalign, operator new, or
   *    operator new[].  Reporters in this category must have units
   *    UNITS_BYTES.
   *  - NONHEAP: reporters measuring memory which the program explicitly
   *    allocated, but does not live on the heap.  Such memory is commonly
   *    allocated by calling one of the OS's memory-mapping functions (e.g.
   *    mmap, VirtualAlloc, or vm_allocate).  Reporters in this category
   *    must have units UNITS_BYTES.
   *  - OTHER: reporters which don't fit into either of these categories.
   *    They can have any units.
   * The kind only matters for reporters in the "explicit" tree;
   * aboutMemory.js uses it to calculate "heap-unclassified".
   * |units|  The units on the reporter's amount.  One of the following.
   *  - BYTES: The amount contains a number of bytes.
   *  - COUNT: The amount is an instantaneous count of things currently in
   *    existence.  For instance, the number of tabs currently open would have
   *    units COUNT.
   *  - COUNT_CUMULATIVE: The amount contains the number of times some event
   *    has occurred since the application started up.  For instance, the
   *    number of times the user has opened a new tab would have units
   *    The amount returned by a reporter with units COUNT_CUMULATIVE must
   *    never decrease over the lifetime of the application.
   *  - PERCENTAGE: The amount contains a fraction that should be expressed as
   *    a percentage.  NOTE!  The |amount| field should be given a value 100x
   *    the actual percentage;  this number will be divided by 100 when shown.
   *    This allows a fractional percentage to be shown even though |amount| is
   *    an integer.  E.g. if the actual percentage is 12.34%, |amount| should
   *    be 1234.
   *    Values greater than 100% are allowed.
   * |amount|  The numeric value reported by this memory reporter.  Accesses
   * can fail if something goes wrong when getting the amount.
   * |description|  A human-readable description of this memory usage report.
  void callback(in ACString process, in AUTF8String path, in int32_t kind,
                in int32_t units, in int64_t amount,
                in AUTF8String description, in nsISupports data);

 * An nsIMemoryReporter reports one or more memory measurements via a
 * callback function which is called once for each measurement.
 * An nsIMemoryReporter that reports a single measurement is sometimes called a
 * "uni-reporter".  One that reports multiple measurements is sometimes called
 * a "multi-reporter".
 * aboutMemory.js is the most important consumer of memory reports.  It
 * places the following constraints on reports.
 * - All reports within a single sub-tree must have the same units.
 * - There may be an "explicit" tree.  If present, it represents
 *   non-overlapping regions of memory that have been explicitly allocated with
 *   an OS-level allocation (e.g. mmap/VirtualAlloc/vm_allocate) or a
 *   heap-level allocation (e.g. malloc/calloc/operator new).  Reporters in
 *   this tree must have kind HEAP or NONHEAP, units BYTES.
 * It is preferred, but not required, that report descriptions use complete
 * sentences (i.e. start with a capital letter and end with a period, or
 * similar).
[scriptable, uuid(0884cd0f-5829-4381-979b-0f53904030ed)]
interface nsIMemoryReporter : nsISupports
   * Run the reporter.
  void collectReports(in nsIMemoryReporterCallback callback,
                      in nsISupports data);

   * Kinds.  See the |kind| comment in nsIMemoryReporterCallback.
  const int32_t KIND_NONHEAP = 0;
  const int32_t KIND_HEAP    = 1;
  const int32_t KIND_OTHER   = 2;

   * Units.  See the |units| comment in nsIMemoryReporterCallback.
  const int32_t UNITS_BYTES = 0;
  const int32_t UNITS_COUNT = 1;
  const int32_t UNITS_COUNT_CUMULATIVE = 2;
  const int32_t UNITS_PERCENTAGE = 3;

[scriptable, function, uuid(548b3909-c04d-4ca6-8466-b8bee3837457)]
interface nsIFinishReportingCallback : nsISupports
  void callback(in nsISupports data);

[scriptable, builtinclass, uuid(e4e4ca56-13e0-46f1-b3c5-62d2c09fc98e)]
interface nsIMemoryReporterManager : nsISupports
   * Initialize.
  void init();

   * Register the given nsIMemoryReporter.  The Manager service will hold a
   * strong reference to the given reporter, and will be responsible for freeing
   * the reporter at shutdown.  You may manually unregister the reporter with
   * unregisterStrongReporter() at any point.
  void registerStrongReporter(in nsIMemoryReporter reporter);

   * Like registerReporter, but the Manager service will hold a weak reference
   * via a raw pointer to the given reporter.  The reporter should be
   * unregistered before shutdown.
   * You cannot register JavaScript components with this function!  Always
   * register your JavaScript components with registerStrongReporter().
  void registerWeakReporter(in nsIMemoryReporter reporter);

   * Unregister the given memory reporter, which must have been registered with
   * registerStrongReporter().  You normally don't need to unregister your
   * strong reporters, as nsIMemoryReporterManager will take care of that at
   * shutdown.
  void unregisterStrongReporter(in nsIMemoryReporter reporter);

   * Unregister the given memory reporter, which must have been registered with
   * registerWeakReporter().
  void unregisterWeakReporter(in nsIMemoryReporter reporter);

   * These functions should only be used for testing purposes.
  void blockRegistrationAndHideExistingReporters();
  void unblockRegistrationAndRestoreOriginalReporters();
  void registerStrongReporterEvenIfBlocked(in nsIMemoryReporter aReporter);

   * Get memory reports for the current process and all child processes.
   * |handleReport| is called for each report, and |finishReporting| is called
   * once all reports have been handled.
   * |finishReporting| is called even if, for example, some child processes
   * fail to report back.  However, calls to this method will silently and
   * immediately abort -- and |finishReporting| will not be called -- if a
   * previous getReports() call is still in flight, i.e. if it has not yet
   * finished invoking |finishReporting|.  The silent abort is because the
   * in-flight request will finish soon, and the caller would very likely just
   * catch and ignore any error anyway.
  void getReports(in nsIMemoryReporterCallback handleReport,
                  in nsISupports handleReportData,
                  in nsIFinishReportingCallback finishReporting,
                  in nsISupports finishReportingData);

   * Get memory reports in the current process only.  |handleReport| is called
   * for each report.
  void getReportsForThisProcess(in nsIMemoryReporterCallback handleReport,
                                in nsISupports handleReportData);

   * The memory reporter manager, for the most part, treats reporters
   * registered with it as a black box.  However, there are some
   * "distinguished" amounts (as could be reported by a memory reporter) that
   * the manager provides as attributes, because they are sufficiently
   * interesting that we want external code (e.g. telemetry) to be able to rely
   * on them.
   * Note that these are not reporters and so getReports() and
   * getReportsForThisProcess() do not look at them.  However, distinguished
   * amounts can be embedded in a reporter.
   * Access to these attributes can fail.  In particular, some of them are not
   * available on all platforms.
   * If you add a new distinguished amount, please update
   * toolkit/components/aboutmemory/tests/test_memoryReporters.xul.
   * |explicit| (UNITS_BYTES)  The total size of explicit memory allocations,
   * both at the OS-level (eg. via mmap, VirtualAlloc) and at the heap level
   * (eg. via malloc, calloc, operator new).  It covers all heap allocations,
   * but will miss any OS-level ones not covered by memory reporters.
   * |vsize| (UNITS_BYTES)  The virtual size, i.e. the amount of address space
   * taken up.
   * |vsizeMaxContiguous| (UNITS_BYTES)  The size of the largest contiguous
   * block of virtual memory.
   * |resident| (UNITS_BYTES)  The resident size (a.k.a. RSS or physical memory
   * used).
   * |residentFast| (UNITS_BYTES)  This is like |resident|, but on Mac OS
   * |resident| can purge pages, which is slow.  It also affects the result of
   * |residentFast|, and so |resident| and |residentFast| should not be used
   * together.
   * |heapAllocated| (UNITS_BYTES)  Memory mapped by the heap allocator.
   * |heapOverheadRatio| (UNITS_PERCENTAGE)  In the heap allocator, this is the
   * ratio of committed, unused bytes to allocated bytes.  Like all
   * UNITS_PERCENTAGE measurements, its amount is multiplied by 100x so it can
   * be represented by an int64_t.
   * |JSMainRuntimeGCHeap| (UNITS_BYTES)  Size of the main JS runtime's GC
   * heap.
   * |JSMainRuntimeTemporaryPeak| (UNITS_BYTES)  Peak size of the transient
   * storage in the main JSRuntime.
   * |JSMainRuntimeCompartments{System,User}| (UNITS_COUNT)  The number of
   * {system,user} compartments in the main JS runtime.
   * |imagesContentUsedUncompressed| (UNITS_BYTES)  Memory used for decoded
   * images in content.
   * |storageSQLite| (UNITS_BYTES)  Memory used by SQLite.
   * |lowMemoryEvents{Virtual,Physical}| (UNITS_COUNT_CUMULATIVE)  The number
   * of low-{virtual,physical}-memory events that have occurred since the
   * process started.
   * |ghostWindows| (UNITS_COUNT)  The number of ghost windows.
   * |pageFaultsHard| (UNITS_COUNT_CUMULATIVE)  The number of hard (a.k.a.
   * major) page faults that have occurred since the process started.
  readonly attribute int64_t explicit;
  readonly attribute int64_t vsize;
  readonly attribute int64_t vsizeMaxContiguous;
  readonly attribute int64_t resident;
  readonly attribute int64_t residentFast;

  readonly attribute int64_t heapAllocated;
  readonly attribute int64_t heapOverheadRatio;

  readonly attribute int64_t JSMainRuntimeGCHeap;
  readonly attribute int64_t JSMainRuntimeTemporaryPeak;
  readonly attribute int64_t JSMainRuntimeCompartmentsSystem;
  readonly attribute int64_t JSMainRuntimeCompartmentsUser;

  readonly attribute int64_t imagesContentUsedUncompressed;

  readonly attribute int64_t storageSQLite;

  readonly attribute int64_t lowMemoryEventsVirtual;
  readonly attribute int64_t lowMemoryEventsPhysical;

  readonly attribute int64_t ghostWindows;

  readonly attribute int64_t pageFaultsHard;

   * This attribute indicates if moz_malloc_usable_size() works.
  [infallible] readonly attribute boolean hasMozMallocUsableSize;

   * Run a series of GC/CC's in an attempt to minimize the application's memory
   * usage.  When we're finished, we invoke the given runnable if it's not
   * null.  Returns a reference to the runnable used for carrying out the task.
  nsICancelableRunnable minimizeMemoryUsage(in nsIRunnable callback);

   * Measure the memory that is known to be owned by this tab, split up into
   * several broad categories.  Note that this will be an underestimate of the
   * true number, due to imperfect memory reporter coverage (corresponding to
   * about:memory's "heap-unclassified"), and due to some memory shared between
   * tabs not being counted.
   * The time taken for the measurement (split into JS and non-JS parts) is
   * also returned.
  void sizeOfTab(in nsIDOMWindow window,
                 out int64_t jsObjectsSize, out int64_t jsStringsSize,
                 out int64_t jsOtherSize, out int64_t domSize,
                 out int64_t styleSize, out int64_t otherSize,
                 out int64_t totalSize,
                 out double jsMilliseconds, out double nonJSMilliseconds);


#include "js/TypeDecls.h"
#include "nsStringGlue.h"
#include "nsTArray.h"
#include "mozilla/Atomics.h"

class nsPIDOMWindow;

// nsIHandleReportCallback is a better name, but keep nsIMemoryReporterCallback
// around for backwards compatibility.
typedef nsIMemoryReporterCallback nsIHandleReportCallback;

namespace mozilla {

// Register a memory reporter.  The manager service will hold a strong
// reference to this reporter.
XPCOM_API(nsresult) RegisterStrongMemoryReporter(nsIMemoryReporter* aReporter);

// Register a memory reporter.  The manager service will hold a weak reference
// to this reporter.
XPCOM_API(nsresult) RegisterWeakMemoryReporter(nsIMemoryReporter* aReporter);

// Unregister a weak memory reporter.
XPCOM_API(nsresult) UnregisterWeakMemoryReporter(nsIMemoryReporter* aReporter);

// The memory reporter manager provides access to several distinguished
// amounts via attributes.  Some of these amounts are provided by Gecko
// components that cannot be accessed directly from XPCOM code.  So we provide
// the following functions for those components to be registered with the
// manager.

typedef int64_t (*InfallibleAmountFn)();
typedef nsresult (*FallibleAmountFn)(int64_t* aAmount);

    nsresult Register##name##DistinguishedAmount(kind##AmountFn aAmountFn);
    nsresult Unregister##name##DistinguishedAmount();

DECL_REGISTER_DISTINGUISHED_AMOUNT(Infallible, JSMainRuntimeCompartmentsSystem)
DECL_REGISTER_DISTINGUISHED_AMOUNT(Infallible, JSMainRuntimeCompartmentsUser)

DECL_REGISTER_DISTINGUISHED_AMOUNT(Infallible, ImagesContentUsedUncompressed)





// Likewise for per-tab measurement.

typedef nsresult (*JSSizeOfTabFn)(JSObject* aObj,
                                  size_t* aJsObjectsSize,
                                  size_t* aJsStringSize,
                                  size_t* aJsPrivateSize,
                                  size_t* aJsOtherSize);
typedef nsresult (*NonJSSizeOfTabFn)(nsPIDOMWindow* aWindow,
                                     size_t* aDomSize,
                                     size_t* aStyleSize,
                                     size_t* aOtherSize);

nsresult RegisterJSSizeOfTab(JSSizeOfTabFn aSizeOfTabFn);
nsresult RegisterNonJSSizeOfTab(NonJSSizeOfTabFn aSizeOfTabFn);


#if defined(MOZ_DMD)
namespace mozilla {
namespace dmd {
// This runs all the memory reporters in the current process but does nothing
// with the results;  i.e. it does the minimal amount of work possible for DMD
// to do its thing.  It does nothing with child processes.
void RunReportersForThisProcess();

#if !defined(MOZ_MEMORY)
#error "MOZ_DMD requires MOZ_MEMORY"

#include "DMD.h"

#define MOZ_REPORT(ptr)          mozilla::dmd::Report(ptr)
#define MOZ_REPORT_ON_ALLOC(ptr) mozilla::dmd::ReportOnAlloc(ptr)


#define MOZ_REPORT(ptr)
#define MOZ_REPORT_ON_ALLOC(ptr)

#endif  // defined(MOZ_DMD)

// Functions generated via this macro should be used by all traversal-based
// memory reporters.  Such functions return |moz_malloc_size_of(ptr)|;  this
// will always be zero on some obscure platforms.
// You might be wondering why we have a macro that creates multiple functions
// that differ only in their name, instead of a single MallocSizeOf function.
// It's mostly to help with DMD integration, though it sometimes also helps
// with debugging and temporary ad hoc profiling.  The function name chosen
// doesn't matter greatly, but it's best to make it similar to the path used by
// the relevant memory reporter(s).
#define MOZ_DEFINE_MALLOC_SIZE_OF(fn)                                         \
  static size_t fn(const void* aPtr)                                          \
  {                                                                           \
      MOZ_REPORT(aPtr);                                                       \
      return moz_malloc_size_of(aPtr);                                        \

// Functions generated by the next two macros should be used by wrapping
// allocators that report heap blocks as soon as they are allocated and
// unreport them as soon as they are freed.  Such allocators are used in cases
// where we have third-party code that we cannot modify.  The two functions
// must always be used in tandem.
#define MOZ_DEFINE_MALLOC_SIZE_OF_ON_ALLOC(fn)                                \
  static size_t fn(const void* aPtr)                                          \
  {                                                                           \
      MOZ_REPORT_ON_ALLOC(aPtr);                                              \
      return moz_malloc_size_of(aPtr);                                        \
#define MOZ_DEFINE_MALLOC_SIZE_OF_ON_FREE(fn)                                 \
  static size_t fn(const void* aPtr)                                          \
  {                                                                           \
      return moz_malloc_size_of(aPtr);                                        \

namespace mozilla {

// This CRTP class handles several details of wrapping allocators and should
// be preferred to manually counting with MOZ_DEFINE_MALLOC_SIZE_OF_ON_ALLOC
// and MOZ_DEFINE_MALLOC_SIZE_OF_ON_FREE.  The typical use is in a memory
// reporter for a particular third party library:
//   class MyMemoryReporter : public CountingAllocatorBase<MyMemoryReporter>
//   {
//     ...
//     CollectReports(nsIHandleReportCallback* aHandleReport, nsISupports* aData)
//     {
//        return MOZ_COLLECT_REPORTER(
//          "explicit/path/to/somewhere", KIND_HEAP, UNITS_BYTES,
//          MemoryAllocated(),
//          "A description of what we are reporting."
//     }
//   };
//   ...somewhere later in the code...
//   SetThirdPartyMemoryFunctions(MyMemoryReporter::CountingAlloc,
//                                MyMemoryReporter::CountingFree);
template<typename T>
class CountingAllocatorBase
#ifdef DEBUG
    // There must be only one instance of this class, due to |sAmount| being
    // static.
    static bool hasRun = false;
    hasRun = true;

  static size_t
    return sAmount;

  static void*
  CountingMalloc(size_t size)
    void* p = malloc(size);
    sAmount += MallocSizeOfOnAlloc(p);
    return p;

  static void*
  CountingCalloc(size_t nmemb, size_t size)
    void* p = calloc(nmemb, size);
    sAmount += MallocSizeOfOnAlloc(p);
    return p;

  static void*
  CountingRealloc(void* p, size_t size)
    size_t oldsize = MallocSizeOfOnFree(p);
    void *pnew = realloc(p, size);
    if (pnew) {
      size_t newsize = MallocSizeOfOnAlloc(pnew);
      sAmount += newsize - oldsize;
    } else if (size == 0) {
      // We asked for a 0-sized (re)allocation of some existing pointer
      // and received NULL in return.  0-sized allocations are permitted
      // to either return NULL or to allocate a unique object per call (!).
      // For a malloc implementation that chooses the second strategy,
      // that allocation may fail (unlikely, but possible).
      // Given a NULL return value and an allocation size of 0, then, we
      // don't know if that means the original pointer was freed or if
      // the allocation of the unique object failed.  If the original
      // pointer was freed, then we have nothing to do here.  If the
      // allocation of the unique object failed, the original pointer is
      // still valid and we ought to undo the decrement from above.
      // However, we have no way of knowing how the underlying realloc
      // implementation is behaving.  Assuming that the original pointer
      // was freed is the safest course of action.  We do, however, need
      // to note that we freed memory.
      sAmount -= oldsize;
    } else {
      // realloc failed.  The amount allocated hasn't changed.
    return pnew;

  static void
  CountingFree(void* p)
    sAmount -= MallocSizeOfOnFree(p);

  // |sAmount| can be (implicitly) accessed by multiple threads, so it
  // must be thread-safe.
  static Atomic<size_t> sAmount;



// This macro assumes the presence of appropriate |aHandleReport| and |aData|
// variables.
#define MOZ_COLLECT_REPORT(path, kind, units, amount, description)            \
  aHandleReport->Callback(EmptyCString(), NS_LITERAL_CSTRING(path),           \
                          kind, units, amount,                                \
                          NS_LITERAL_CSTRING(description), aData)