Adjust interfaces to indicate when tracking is in progress

base/tracked_objects.h

 // Copyright (c) 2011 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 BASE_TRACKED_OBJECTS_H_
 #define BASE_TRACKED_OBJECTS_H_
 #pragma once
 
 #include <map>
 #include <stack>
 #include <string>
 #include <vector>
 
 #include "base/base_export.h"
 #include "base/location.h"
 #include "base/profiler/tracked_time.h"
 #include "base/time.h"
 #include "base/synchronization/lock.h"
 #include "base/threading/thread_local_storage.h"
 #include "base/tracking_info.h"
 #include "base/values.h"
 
 // TrackedObjects provides a database of stats about objects (generally Tasks)
 // that are tracked.  Tracking means their birth, death, duration, birth thread,
 // death thread, and birth place are recorded.  This data is carefully spread
 // across a series of objects so that the counts and times can be rapidly
 // updated without (usually) having to lock the data, and hence there is usually
 // very little contention caused by the tracking.  The data can be viewed via
-// the about:tracking URL, with a variety of sorting and filtering choices.
+// the about:profiler URL, with a variety of sorting and filtering choices.
 //
 // These classes serve as the basis of a profiler of sorts for the Tasks system.
 // As a result, design decisions were made to maximize speed, by minimizing
 // recurring allocation/deallocation, lock contention and data copying.  In the
 // "stable" state, which is reached relatively quickly, there is no separate
 // marginal allocation cost associated with construction or destruction of
 // tracked objects, no locks are generally employed, and probably the largest
 // computational cost is associated with obtaining start and stop times for
 // instances as they are created and destroyed.
 //
@@ skipping 71 matching lines @@
 // requires the use of the list_lock_.
 // When new ThreadData instances is added to the global list, it is pre-pended,
 // which ensures that any prior acquisition of the list is valid (i.e., the
 // holder can iterate over it without fear of it changing, or the necessity of
 // using an additional lock.  Iterations are actually pretty rare (used
 // primarilly for cleanup, or snapshotting data for display), so this lock has
 // very little global performance impact.
 //
 // The above description tries to define the high performance (run time)
 // portions of these classes.  After gathering statistics, calls instigated
-// by visiting about:tracking will assemble and aggregate data for display.  The
+// by visiting about:profiler will assemble and aggregate data for display.  The
 // following data structures are used for producing such displays.  They are
 // not performance critical, and their only major constraint is that they should
 // be able to run concurrently with ongoing augmentation of the birth and death
 // data.
 //
 // For a given birth location, information about births is spread across data
 // structures that are asynchronously changing on various threads.  For display
 // purposes, we need to construct Snapshot instances for each combination of
 // birth thread, death thread, and location, along with the count of such
 // lifetimes.  We gather such data into a Snapshot instances, so that such
@@ skipping 14 matching lines @@
 // of a bad memory reference).
 //
 // After an array of Snapshots instances are collected into a DataCollector,
 // they need to be prepared for displaying our output.  We currently implement a
 // direct rendering to HTML, but we will soon have a JSON serialization as well.
 
 // For direct HTML display, the data must be sorted, and possibly aggregated
 // (example: how many threads are in a specific consecutive set of Snapshots?
 // What was the total birth count for that set? etc.).  Aggregation instances
 // collect running sums of any set of snapshot instances, and are used to print
-// sub-totals in an about:tracking page.
+// sub-totals in an about:profiler page.
 //
 // TODO(jar): I need to store DataCollections, and provide facilities for taking
 // the difference between two gathered DataCollections.  For now, I'm just
 // adding a hack that Reset()s to zero all counts and stats.  This is also
 // done in a slighly thread-unsafe fashion, as the resetting is done
 // asynchronously relative to ongoing updates (but all data is 32 bit in size).
 // For basic profiling, this will work "most of the time," and should be
 // sufficient... but storing away DataCollections is the "right way" to do this.
 // We'll accomplish this via JavaScript storage of snapshots, and then we'll
 // remove the Reset() methods.
@@ skipping 489 matching lines @@
   // Initializes all statics if needed (this initialization call should be made
   // while we are single threaded). Returns false if unable to initialize.
   static bool Initialize();
 
   // Sets internal status_ to either become ACTIVE, or DEACTIVATED,
   // based on argument being true or false respectively.
   // If tracking is not compiled in, this function will return false.
   static bool InitializeAndSetTrackingStatus(bool status);
   static bool tracking_status();
 
+  // Special versions of Now() for getting times at start and end of a tracked
+  // run.  They are super fast when tracking is disabled, and have some internal
+  // side effects when we are tracking, so that we can deduce the amount of time
+  // accumulated outside of execution of tracked runs.
+  static TrackedTime NowForStartOfRun();
+  static TrackedTime NowForEndOfRun();
+
   // Provide a time function that does nothing (runs fast) when we don't have
   // the profiler enabled.  It will generally be optimized away when it is
   // ifdef'ed to be small enough (allowing the profiler to be "compiled out" of
   // the code).
   static TrackedTime Now();
 
  private:
   // Allow only tests to call ShutdownSingleThreadedCleanup.  We NEVER call it
   // in production code.
   friend class TrackedObjectsTest;
@@ skipping 39 matching lines @@
   // threads since the time that InitializeAndSetTrackingStatus() was called,
   // then you can pass in a |leak| value of false, and this function will
   // delete recursively all data structures, starting with the list of
   // ThreadData instances.
   static void ShutdownSingleThreadedCleanup(bool leak);
 
   // We use thread local store to identify which ThreadData to interact with.
   static base::ThreadLocalStorage::Slot tls_index_;
 
   // Link to the most recently created instance (starts a null terminated list).
-  // The list is traversed by about:tracking when it needs to snapshot data.
+  // The list is traversed by about:profiler when it needs to snapshot data.
   // This is only accessed while list_lock_ is held.
   static ThreadData* all_thread_data_list_head_;
   // Set of ThreadData instances for use with worker threads. When a worker
   // thread is done (terminating), we push it into this pool.  When a new worker
   // thread is created, we first try to re-use a ThreadData instance from the
   // pool, and if none are available, construct a new one.
   // This is only accessed while list_lock_ is held.
   static ThreadDataPool* unregistered_thread_data_pool_;
   // The next available thread number.  This should only be accessed when the
   // list_lock_ is held.
@@ skipping 71 matching lines @@
   }
 
  private:
 
   DISALLOW_COPY_AND_ASSIGN(AutoTracking);
 };
 
 }  // namespace tracked_objects
 
 #endif  // BASE_TRACKED_OBJECTS_H_