[UMA] Use proper C++ objects to serialize tracked_objects across process boundaries.

base/profiler/tracked_time.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_PROFILER_TRACKED_TIME_H_
 #define BASE_PROFILER_TRACKED_TIME_H_
 
 
 #include "base/base_export.h"
 #include "base/basictypes.h"
 #include "base/time.h"
 
 namespace tracked_objects {
 
+// TODO(isherman): Shouldn't this be explicitly an int32 or something like that?

[jar (doing other things), 2012/03/21 18:19:55]

I think a change to int32 would be good.  This typedef was (as I recall) used as
an internal optimization to get closer to what we needed sooner in the call
stack.

When reading and writing these values, we do count on them being atomically
written or read (i.e., you can't get a partial read or write) on all our
platforms.  I'm careful to avoid the need for barriers and locks.  It *could* be
that to be super careful, these should be changed to atomics, with non-barrier
accesses...  but the smaller change to an explicit int32 seems like a good idea.

[Ilya Sherman, 2012/03/21 21:45:43]

Ah, looks like we are already using int32 within this header.  I've split this
bit of cleanup off into https://chromiumcodereview.appspot.com/9818004/

 typedef int DurationInt;
 
 //------------------------------------------------------------------------------
 
 #define USE_FAST_TIME_CLASS_FOR_DURATION_CALCULATIONS
 
 #if defined(USE_FAST_TIME_CLASS_FOR_DURATION_CALCULATIONS)
 
 // TimeTicks maintains a wasteful 64 bits of data (we need less than 32), and on
 // windows, a 64 bit timer is expensive to even obtain. We use a simple
@@ skipping 54 matching lines @@
 // with a more thoroughly tested class.
 
 typedef base::TimeTicks TrackedTime;
 typedef base::TimeDelta Duration;
 
 #endif  // USE_FAST_TIME_CLASS_FOR_DURATION_CALCULATIONS
 
 }  // namespace tracked_objects
 
 #endif  // BASE_PROFILER_TRACKED_TIME_H_