Delete Tracked, and move Location to its own file.

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 <string>
 #include <vector>
 
 #include "base/base_export.h"
+#include "base/location.h"
+#include "base/time.h"
 #include "base/synchronization/lock.h"
-#include "base/tracked.h"
 #include "base/threading/thread_local_storage.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:tasks URL, with a variety of sorting and filtering choices.
 //
@@ skipping 24 matching lines @@
 // BirthOnThread) references to the static data provided in a Location instance,
 // as well as a pointer specifying the thread on which the birth takes place.
 // Hence there is at most one Births instance for each Location on each thread.
 // The derived Births class contains slots for recording statistics about all
 // instances born at the same location.  Statistics currently include only the
 // count of instances constructed.
 // Since the base class BirthOnThread contains only constant data, it can be
 // freely accessed by any thread at any time (i.e., only the statistic needs to
 // be handled carefully, and it is ONLY read or written by the birth thread).
 //
-// Having now either constructed or found the Births instance described above, a
-// pointer to the Births instance is then embedded in a base class of the
-// instance we're tracking (usually a Task). This fact alone is very useful in
+// For Tasks, having now either constructed or found the Births instance
+// described above, a pointer to the Births instance is then recorded into the
+// PendingTask structure in MessageLoop.  This fact alone is very useful in
 // debugging, when there is a question of where an instance came from.  In
-// addition, the birth time is also embedded in the base class Tracked (see
-// tracked.h), and used to later evaluate the lifetime duration.
-// As a result of the above embedding, we can (for any tracked instance) find
-// out its location of birth, and thread of birth, without using any locks, as
-// all that data is constant across the life of the process.
+// addition, the birth time is also recorded and used to later evaluate the
+// lifetime duration of the whole Task.  As a result of the above embedding, we
+// can find out a Task's location of birth, and thread of birth, without using
+// any locks, as all that data is constant across the life of the process.
+//
+// This can also be done for any other object as well by calling
+// TallyABirthIfActive() and TallyADeathIfActive() as appropriate.
 //
 // The amount of memory used in the above data structures depends on how many
 // threads there are, and how many Locations of construction there are.
 // Fortunately, we don't use memory that is the product of those two counts, but
 // rather we only need one Births instance for each thread that constructs an
-// instance at a Location. In many cases, instances (such as Tasks) are only
-// created on one thread, so the memory utilization is actually fairly
-// restrained.
+// instance at a Location. In many cases, instances are only created on one
+// thread, so the memory utilization is actually fairly restrained.
 //
 // Lastly, when an instance is deleted, the final tallies of statistics are
 // carefully accumulated.  That tallying wrties into slots (members) in a
 // collection of DeathData instances.  For each birth place Location that is
 // destroyed on a thread, there is a DeathData instance to record the additional
 // death count, as well as accumulate the lifetime duration of the instance as
 // it is destroyed (dies).  By maintaining a single place to aggregate this
 // addition *only* for the given thread, we avoid the need to lock such
 // DeathData instances.
 //
@@ skipping 53 matching lines @@
 // snapshot instances, and are used to print sub-totals in an about:tasks 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 reseting is done
 // asynchronously relative to ongoing updates, and worse yet, some data fields
 // are 64bit quantities, and are not atomicly accessed (reset or incremented
 // etc.).  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.
-//
+
 class MessageLoop;
 
-
 namespace tracked_objects {
 
 //------------------------------------------------------------------------------
 // For a specific thread, and a specific birth place, the collection of all
 // death info (with tallies for each death thread, to prevent access conflicts).
 class ThreadData;
 class BASE_EXPORT BirthOnThread {
  public:
   explicit BirthOnThread(const Location& location);
 
@@ skipping 502 matching lines @@
   };
   static State state_;
 
   DISALLOW_COPY_AND_ASSIGN(AutoTracking);
 };
 
 
 }  // namespace tracked_objects
 
 #endif  // BASE_TRACKED_OBJECTS_H_