Tracelogger currently uses rdtsc whenever possible. However, this records cycles which can vary from machine to machine and is also susceptible to being throttled. The timestamps need to be recorded using a monotonic clock so that they can line up properly with the profiler samples and markers.

Tracelogger events need to be timestamped by a monotonic clock so that these events can line up with the gecko profiler start time. The idea here is to continue using rdtsc if the CPU supports an invariant TSC (which is true for most modern x86 processors), and interpolate these values to the values from mozilla::TimeStamp. If the CPU does not support an invariant TSC, then just fall back to mozilla::TimeStamp for timekeeping.

I think the best approach right now is to use mozilla::TimeStamp for timing in the tracelogger. This already uses nanosecond timing on OSX, Linux, and Windows through mach_absolute_time, clock_gettime, and QueryPerformanceCounter respectively, and in practice is actually quite fast. The biggest overhead is on Windows of about 3-4%. For Linux, it is around 2%. Ultimately, we should use redesign this so that we're using rdtscp whenever an invariant TSC is supported. However, I need to test this thoroughly on all 3 platforms so I would prefer to defer that in a follow up bug once the new tracelogger implementation is landed for use.

Switch over to mozilla::TimeStamp for timing. This should use clock_gettime, mach_absolute_time, ,and QueryPerformanceCounter timing implementations on Linux, OSX, and Windows which are all very efficient. It increases overhead a little bit, but allows for synchronization across cores and the profiler, and is portable. Longer term solution should be to move over to rdtscp for timing.

Pushed by apavel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/713199b324b4 Use mozilla::TimeStamp for tracelogger timing r=sfink