Minor spelling fixes in base/tracked_objects.

base/tracked_objects.h

 // Copyright (c) 2012 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_
 
 #include <map>
 #include <set>
 #include <stack>
@@ skipping 25 matching lines @@
 //
 // 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.
 //
-// The following describes the lifecycle of tracking an instance.
+// The following describes the life cycle of tracking an instance.
 //
 // First off, when the instance is created, the FROM_HERE macro is expanded
 // to specify the birth place (file, line, function) where the instance was
 // created.  That data is used to create a transient Location instance
 // encapsulating the above triple of information.  The strings (like __FILE__)
 // are passed around by reference, with the assumption that they are static, and
 // will never go away.  This ensures that the strings can be dealt with as atoms
 // with great efficiency (i.e., copying of strings is never needed, and
 // comparisons for equality can be based on pointer comparisons).
 //
@@ skipping 32 matching lines @@
 // Lastly, when an instance is deleted, the final tallies of statistics are
 // carefully accumulated.  That tallying writes 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 run-time and queue-time durations for
 // the instance as it is destroyed (dies).  By maintaining a single place to
 // aggregate this running sum *only* for the given thread, we avoid the need to
 // lock such DeathData instances. (i.e., these accumulated stats in a DeathData
 // instance are exclusively updated by the singular owning thread).
 //
-// With the above lifecycle description complete, the major remaining detail is
-// explaining how each thread maintains a list of DeathData instances, and of
-// Births instances, and is able to avoid additional (redundant/unnecessary)
+// With the above life cycle description complete, the major remaining detail
+// is explaining how each thread maintains a list of DeathData instances, and
+// of Births instances, and is able to avoid additional (redundant/unnecessary)
 // allocations.
 //
 // Each thread maintains a list of data items specific to that thread in a
 // ThreadData instance (for that specific thread only).  The two critical items
 // are lists of DeathData and Births instances.  These lists are maintained in
 // STL maps, which are indexed by Location. As noted earlier, we can compare
 // locations very efficiently as we consider the underlying data (file,
 // function, line) to be atoms, and hence pointer comparison is used rather than
 // (slow) string comparisons.
 //
 // To provide a mechanism for iterating over all "known threads," which means
 // threads that have recorded a birth or a death, we create a singly linked list
 // of ThreadData instances. Each such instance maintains a pointer to the next
 // one.  A static member of ThreadData provides a pointer to the first item on
 // this global list, and access via that all_thread_data_list_head_ item
 // 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
+// primarily 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: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.
 //
@@ skipping 16 matching lines @@
 // The ProcessDataSnapshot struct is a serialized representation of the list
 // of ThreadData objects for a process.  It holds a set of TaskSnapshots
 // and tracks parent/child relationships for the executed tasks.  The statistics
 // in a snapshot are gathered asynhcronously relative to their ongoing updates.
 // It is possible, though highly unlikely, that stats could be incorrectly
 // recorded by this process (all data is held in 32 bit ints, but we are not
 // atomically collecting all data, so we could have count that does not, for
 // example, match with the number of durations we accumulated).  The advantage
 // to having fast (non-atomic) updates of the data outweighs the minimal risk of
 // a singular corrupt statistic snapshot (only the snapshot could be corrupt,
-// not the underlying and ongoing statistic).  In constrast, pointer data that
+// not the underlying and ongoing statistic).  In contrast, pointer data that
 // is accessed during snapshotting is completely invariant, and hence is
 // perfectly acquired (i.e., no potential corruption, and no risk of a bad
 // memory reference).
 //
 // TODO(jar): We can implement a Snapshot system that *tries* to grab the
 // snapshots on the source threads *when* they have MessageLoops available
 // (worker threads don't have message loops generally, and hence gathering from
 // them will continue to be asynchronous).  We had an implementation of this in
 // the past, but the difficulty is dealing with message loops being terminated.
 // We can *try* to spam the available threads via some message loop proxy to
-// achieve this feat, and it *might* be valuable when we are colecting data for
-// upload via UMA (where correctness of data may be more significant than for a
-// single screen of about:profiler).
+// achieve this feat, and it *might* be valuable when we are collecting data
+// for upload via UMA (where correctness of data may be more significant than
+// for a single screen of about:profiler).
 //
 // TODO(jar): We should support (optionally) the recording of parent-child
 // relationships for tasks.  This should be done by detecting what tasks are
 // Born during the running of a parent task.  The resulting data can be used by
 // a smarter profiler to aggregate the cost of a series of child tasks into
 // the ancestor task.  It can also be used to illuminate what child or parent is
 // related to each task.
 //
 // TODO(jar): We need to store DataCollections, and provide facilities for
 // taking the difference between two gathered DataCollections.  For now, we're
 // 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
+// done in a slightly 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.  We may also need a short-term-max value in
 // DeathData that is reset (as synchronously as possible) during each snapshot.
 // This will facilitate displaying a max value for each snapshot period.
 
 namespace tracked_objects {
 
@@ skipping 159 matching lines @@
 struct ProcessDataSnapshot;
 class BASE_EXPORT TaskStopwatch;
 
 class BASE_EXPORT ThreadData {
  public:
   // Current allowable states of the tracking system.  The states can vary
   // between ACTIVE and DEACTIVATED, but can never go back to UNINITIALIZED.
   enum Status {
     UNINITIALIZED,              // PRistine, link-time state before running.
     DORMANT_DURING_TESTS,       // Only used during testing.
-    DEACTIVATED,                // No longer recording profling.
+    DEACTIVATED,                // No longer recording profiling.
     PROFILING_ACTIVE,           // Recording profiles (no parent-child links).
     PROFILING_CHILDREN_ACTIVE,  // Fully active, recording parent-child links.
     STATUS_LAST = PROFILING_CHILDREN_ACTIVE
   };
 
   typedef std::map<Location, Births*> BirthMap;
   typedef std::map<const Births*, DeathData> DeathMap;
   typedef std::pair<const Births*, const Births*> ParentChildPair;
   typedef std::set<ParentChildPair> ParentChildSet;
   typedef std::stack<const Births*> ParentStack;
@@ skipping 169 matching lines @@
   // living instances of the task -- that is, each task maps to the number of
   // births for the task that have not yet been balanced by a death.  If
   // |reset_max| is true, then the max values in each DeathData instance are
   // reset during the scan.
   void SnapshotExecutedTasks(bool reset_max,
                              ProcessDataSnapshot* process_data,
                              BirthCountMap* birth_counts);
 
   // Using our lock, make a copy of the specified maps.  This call may be made
   // on  non-local threads, which necessitate the use of the lock to prevent
-  // the map(s) from being reallocaed while they are copied. If |reset_max| is
+  // the map(s) from being reallocated while they are copied. If |reset_max| is
   // true, then, just after we copy the DeathMap, we will set the max values to
   // zero in the active DeathMap (not the snapshot).
   void SnapshotMaps(bool reset_max,
                     BirthMap* birth_map,
                     DeathMap* death_map,
                     ParentChildSet* parent_child_set);
 
   // Using our lock to protect the iteration, Clear all birth and death data.
   void Reset();
 
@@ skipping 21 matching lines @@
   static NowFunction* now_function_;
 
   // If true, now_function_ returns values that can be used to calculate queue
   // time.
   static bool now_function_is_time_;
 
   // We use thread local store to identify which ThreadData to interact with.
   static base::ThreadLocalStorage::StaticSlot tls_index_;
 
   // List of ThreadData instances for use with worker threads. When a worker
-  // thread is done (terminated), we push it onto this llist.  When a new worker
+  // thread is done (terminated), we push it onto this list.  When a new worker
   // thread is created, we first try to re-use a ThreadData instance from the
   // list, and if none are available, construct a new one.
   // This is only accessed while list_lock_ is held.
   static ThreadData* first_retired_worker_;
 
   // Link to the most recently created instance (starts a null terminated list).
   // 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_;
 
@@ skipping 62 matching lines @@
   // thread, or reading from another thread.  For reading from this thread we
   // don't need a lock, as there is no potential for a conflict since the
   // writing is only done from this thread.
   mutable base::Lock map_lock_;
 
   // The stack of parents that are currently being profiled. This includes only
   // tasks that have started a timer recently via PrepareForStartOfRun(), but
   // not yet concluded with a NowForEndOfRun().  Usually this stack is one deep,
   // but if a scoped region is profiled, or <sigh> a task runs a nested-message
   // loop, then the stack can grow larger.  Note that we don't try to deduct
-  // time in nested porfiles, as our current timer is based on wall-clock time,
+  // time in nested profiles, as our current timer is based on wall-clock time,
   // and not CPU time (and we're hopeful that nested timing won't be a
   // significant additional cost).
   ParentStack parent_stack_;
 
   // A random number that we used to select decide which sample to keep as a
   // representative sample in each DeathData instance.  We can't start off with
   // much randomness (because we can't call RandInt() on all our threads), so
   // we stir in more and more as we go.
   uint32 random_number_;
 
@@ skipping 94 matching lines @@
   ~ProcessDataSnapshot();
 
   std::vector<TaskSnapshot> tasks;
   std::vector<ParentChildPairSnapshot> descendants;
   int process_id;
 };
 
 }  // namespace tracked_objects
 
 #endif  // BASE_TRACKED_OBJECTS_H_