summaryrefslogtreecommitdiffstats
path: root/base/time
Commit message (Collapse)AuthorAgeFilesLines
* clang/win: Let some chromium_code targets build with -Wextra.thakis2015-12-101-5/+1
| | | | | | | | | | | | | | | | | | | To make warning flags between Windows and non-Windows clang consistent, I'd like to build chromium_code targets with -Wextra enabled. This fixes -Wextra warnings in about 14k of 31k build steps. Most of the warnings were about signed/unsigned mismatches; some were about "const"s that had no effect. (This CL does not contain the change to actually turn on -Wextra, only cleanups.) BUG=567877 TBR=content/common/sandbox Review URL: https://codereview.chromium.org/1507413003 Cr-Commit-Position: refs/heads/master@{#364232}
* Switch to static_assert in base/.avi2015-11-242-6/+6
| | | | | | | | BUG=442514 Review URL: https://codereview.chromium.org/1467003002 Cr-Commit-Position: refs/heads/master@{#361337}
* Kills TraceTicks, which was functionally the same as TimeTickscharliea2015-11-057-96/+7
| | | | | | | | | | | | | This was not true until last week's submission of http://crrev.com/1374753004. BUG=541692 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel NO_PRESUBMIT=true Review URL: https://codereview.chromium.org/1424703003 Cr-Commit-Position: refs/heads/master@{#358047}
* Avoid const int definition problemsbrucedawson2015-11-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | VC++ up to VS 2015 RTM does not require explicit storage allocation for static const integers declared in classes. VS 2015 Update 1 requires these storage definitions in some cases. In order to avoid #ifs around the storage definitions this change switches the problematic consts to enums, for maximum portability. Where needed the enums have types specified. Many previous versions of VC++ have theoretically *allowed* a definition to supply storage, but tests on VC++ 2013 show that this doesn't actually work correctly - it leads to duplicate definition errors. So, enums are the only #if option. With this change all targets build with the latest VS 2015. See also 1422453005. R=danakj@chromium.org,zmo@chromium.org BUG=440500 Review URL: https://codereview.chromium.org/1428003002 Cr-Commit-Position: refs/heads/master@{#357688}
* Makes TraceTicks use the monotonic timer on Chrome OScharliea2015-10-221-16/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the end result of an effort to eliminate the need for TraceTicks to be based on the ftrace clock on Chrome OS. Chrome tracing began using the ftrace clock so that we could correlate what was happening in Chrome (recorded in Chrome traces and thus based on TraceTicks) with what was happening inside of the ChromeOS kernel (and thus based on the ftrace clock). Having this end-to-end view of performance was necessary for full-stack debugging on Chrome OS. However, a May 2015 Linux patch (https://goo.gl/2Or7DF) added the ability to use the monotonic clock as the source for timestamps within ftrace. This allows us to use the monotonic clock for ftrace and thus have the benefits of having consistent timestamps in our Chrome-level and kernel-level tracing tools, without the cost of having to carry around timestamps from two different sources within Chrome (the monotonic clock for TimeTicks and the ftrace clock for TraceTicks). sonnyrao@ graciously volunteered to backport this Linux patch to major past versions of Chrome OS, paving the way for this patch which finally starts using the monotonic timer for TraceTicks on Chrome OS. He's ready to submit the second side of this CL which tells ftrace to start using the monotonic clock as soon as this one gets DEPS rolled into ChromeOS (sometime tomorrow morning). The one down-side to all of this is that, once sonnyrao@ completes the backports and this patch is submitted, developers with the latest version of Chrome but with a version of ChromeOS that is not within the most recent 5 versions will have ftrace timestamps that do not match Chrome tracing timestamps. This shouldn't cause any functional problems, but it will make it harder to get a full picture of Chrome's performance down to the kernel level. BUG=541692 Review URL: https://codereview.chromium.org/1374753004 Cr-Commit-Position: refs/heads/master@{#355650}
* mac: Make Mach port scopers better ScopedGenericsmark2015-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Previously, Pass() did not work correctly for ScopedMachReceiveRight, ScopedMachSendRight, or ScopedMachPortSet. These were defined as subclasses of ScopedGeneric<> with appropriate traits types. They did not have the full range of constructors made available by ScopedGeneric<>, and their Pass() methods referred to their ScopedGeneric<> superclass rather than their proper class types. This changes these scopers to work as ScopedGeneric<> intends, with a "using" or "typedef" declaration, so that names such as ScopedMachReceiveRight actually refer to the same type as the underlying ScopedGeneric<>. This allows Pass() and all other ScopedGeneric<> functionality to work as intended. Unfortunately, ScopedGeneric<> doesn't provide a type conversion operator to the underlying wrapped type, so many use sites need to be transformed to use the get() accessor. Many existing use sites already used this accessor. Review URL: https://codereview.chromium.org/1411523006 Cr-Commit-Position: refs/heads/master@{#355112}
* Fix units in comment in time_win.cc from milli to micro.gab2015-10-191-2/+2
| | | | | | | | BUG=None Review URL: https://codereview.chromium.org/1409863004 Cr-Commit-Position: refs/heads/master@{#354867}
* Implement ThreadTicks::Now on Windows.fdoray2015-10-154-23/+178
| | | | | | | | | | | | | | | | | | | | Use QueryThreadCycleTime() to get the number of CPU clock cycles used by the current thread. Convert it to microseconds using a measured TSC frequency. The value returned by QueryThreadCycleTime() is based on the rdtsc instruction. For several years, Intel has been shipping CPUs with a constant-rate counter, which means that the QueryThreadCycleTime() results are directly proportional to wall-clock time on most systems (see crbug.com/280743#c15). ThreadTicks::IsSupported() will return false if the CPU doesn't have a constant rate TSC. BUG=280743 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1390743002 Cr-Commit-Position: refs/heads/master@{#354213}
* Disable TimeTicks.WinRollover under ASanrnk2015-10-091-1/+8
| | | | | | | | | | | | It spawns lots of threads and can occasionally fail due to address space exhaustion. BUG=541675 R=thakis@chromium.org Review URL: https://codereview.chromium.org/1390933006 Cr-Commit-Position: refs/heads/master@{#353382}
* Emphasizes that TimeTicks::UnixEpoch() is only an estimatecharliea2015-10-071-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the case because of its implementation: - Use Time::Now() to determine the current distance to the Unix epoch - Subtract that distance from TimeTicks::Now(), giving you an approximation of that epoch in TimeTicks However, this can lead to strange situations: - If a system experiences a large NTP adjustment (say, after being offline for a while), then Time::Now() will immediately jump to the new time, whereas TimeTicks::Now() will very slightly speed up or slow down the clock until the monotonic clock matches what's thought to be the "correct" time. However, this means that for a 10 second NTP adjustment, calling TimeTicks::UnixEpoch() a second before the adjustment will yield a 10 second difference from calling it after the adjustment. - The same is true for when the user manually sets the clock. Any monotonic clock (those used for TimeTicks) is resistant to such user intervention, whereas any wall clock (used for Time) is usually not. Thus, calling TimeTicks::UnixEpoch() a second before such an adjustment will yield a vastly different epoch estimate than calling it after the adjustment. Both of these are somewhat surprising results for a TimeTicks function, as it's generally safe to assume that TimeTicks functions are immune to these strange jumps. Given all of this, I think TimeTicks::UnixEpoch() needed a slightly stronger warning about the fact that it's only an estimate. Review URL: https://codereview.chromium.org/1391323002 Cr-Commit-Position: refs/heads/master@{#352952}
* Revert of Check for CloseHandle failures even when not debugging (patchset ↵brucedawson2015-09-181-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | #4 id:60001 of https://codereview.chromium.org/1350493002/ ) Reason for revert: The SharedMemory checks are causing CHECK crashes in the printing system. See bug 533310. Reverting to allow time for an investigation of that underlying problem. Original issue's description: > Check for CloseHandle failures even when not debugging > > Bug 524267 was a handle closing failure that only showed up when running > renderer processes under a debugger at startup, so it was not discovered > for a while. > > Similarly, bug 520305 is a long-standing base_unittests bug that only > shows up under a debugger. > > This change fixes 520305 and checks for many handle closing failures > always so that subsequent bugs of this type will be detected > immediately. > > Most of the CloseHandle calls in base are now checked. > > This replaces the uncommitted https://codereview.chromium.org/1343873002/ > > R=grt@chromium.org,rvargas@chromium.org,dalecurtis@chromium.org > BUG=524267,520305 > > Committed: https://crrev.com/9ae49a753d07f5a9266a63a89e7336d774f3fe37 > Cr-Commit-Position: refs/heads/master@{#349333} TBR=dalecurtis@chromium.org,grt@chromium.org,rvargas@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=524267,520305 Review URL: https://codereview.chromium.org/1356743003 Cr-Commit-Position: refs/heads/master@{#349716}
* Check for CloseHandle failures even when not debuggingbrucedawson2015-09-171-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | Bug 524267 was a handle closing failure that only showed up when running renderer processes under a debugger at startup, so it was not discovered for a while. Similarly, bug 520305 is a long-standing base_unittests bug that only shows up under a debugger. This change fixes 520305 and checks for many handle closing failures always so that subsequent bugs of this type will be detected immediately. Most of the CloseHandle calls in base are now checked. This replaces the uncommitted https://codereview.chromium.org/1343873002/ R=grt@chromium.org,rvargas@chromium.org,dalecurtis@chromium.org BUG=524267,520305 Review URL: https://codereview.chromium.org/1350493002 Cr-Commit-Position: refs/heads/master@{#349333}
* Fix clang/win build after https://codereview.chromium.org/1284053004/Nico Weber2015-08-251-1/+0
| | | | | | | | | | | | The change removed a function, but not its declaration, angering -Wunused-function. BUG=345845,82385 TBR=charliea Review URL: https://codereview.chromium.org/1312313002 . Cr-Commit-Position: refs/heads/master@{#345460}
* Makes TraceTicks use lowres times on Win when highres are buggy or slowcharliea2015-08-251-29/+26
| | | | | | | | | | | | | | | | We're doing this so that we can eventually consolidate TraceTicks and TimeTicks and have one type of timestamp that is reliable, monotonic, and comparable. Also, using the high-resolution clock when it's unreliable or slow is of questionable benefit, as it's easier to make tracing tools accommodate a coarse timer than one that's unreliable or slow. BUG=345845 Review URL: https://codereview.chromium.org/1284053004 Cr-Commit-Position: refs/heads/master@{#345449}
* Base: Make TimeDelta constructors deal with overflow.rvargas2015-07-273-84/+100
| | | | | | | | | | | | | BUG=466445 TBR=skuhne@chromium.org, enne@chromium.org, jochen@chromium.org, kbr@chromium.org Committed: https://crrev.com/15462e858ebf34721e28a023b0b670c2011183ac Cr-Commit-Position: refs/heads/master@{#339605} CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1229853004 Cr-Commit-Position: refs/heads/master@{#340541}
* Revert of Base: Make TimeDelta constructors deal with overflow. (patchset #2 ↵antrim2015-07-213-100/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | id:20001 of https://codereview.chromium.org/1229853004/) Reason for revert: Reverting CL: it seems to cause regression in number of static initializers. For details see https://code.google.com/p/chromium/issues/detail?id=512348 Original issue's description: > Base: Make TimeDelta constructors deal with overflow. > > BUG=466445 > > Committed: https://crrev.com/15462e858ebf34721e28a023b0b670c2011183ac > Cr-Commit-Position: refs/heads/master@{#339605} TBR=thakis@chromium.org,rvargas@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=466445 Review URL: https://codereview.chromium.org/1250453004 Cr-Commit-Position: refs/heads/master@{#339641}
* Base: Make TimeDelta constructors deal with overflow.rvargas2015-07-213-84/+100
| | | | | | | | BUG=466445 Review URL: https://codereview.chromium.org/1229853004 Cr-Commit-Position: refs/heads/master@{#339605}
* Fix some clang warnings with -Wmissing-braces in base.dcheng2015-07-021-1/+1
| | | | | | | | | | | | | | | | Clang warns if there are missing braces around a subobject initializer. The most common idiom that triggers this is: STRUCT s = {0}; if the first field of STRUCT is itself a struct. This can be more simply written as: STRUCT s = {}; which also prevents the warning from firing. BUG=505297 Review URL: https://codereview.chromium.org/1218243002 Cr-Commit-Position: refs/heads/master@{#337139}
* Remove base/port.h includes that are not necessary anymore.tfarina2015-06-111-1/+0
| | | | | | | | | | | | | There is almost nothing remaining in port.h, just the API_CALL macro. Since these files are not using it we can remove this include from them. BUG=138542 R=thestig@chromium.org,mnissler@chromium.org,dmazzoni@chromium.org,dalecurtis@chromium.org,mattm@chromium.org,zea@chromium.org Review URL: https://codereview.chromium.org/1181713004 Cr-Commit-Position: refs/heads/master@{#334080}
* Fixit: Fork base::TimeTicks --> TimeTicks + ThreadTicks + TraceTicksmiu2015-05-297-128/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | | TimeTicks was being overused for time values from three different clock sources. This change splits the class into three separate classes: The general-purpose monotonic time (TimeTicks), the thread-local run time (ThreadTicks), and the global system trace time (TraceTicks). With this change, the compiler is now able to use type-checking to guarantee values from different clocks are not being mixed when doing time math. This is the 2nd in a two-part change. Part 1 factored-out the comparison and math operator overloads common to base::Time and base::TimeTicks into a templated base class. The new ThreadTicks and TraceTicks time classes also inherit from that base class. Updated base/trace_event/* and a handful of outside-of-base uses of ThreadNow() and NowFromSystemTraceTime() to use the new classes. A bug was identified and fixed, in src/ui/gl/angle_platform_impl.cc, where values from TimeTicks::Now() were being erroneously provided to base::TraceEvent instead of values from NowFromSystemTraceTime(). BUG=467417 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel NOTRY=true Review URL: https://codereview.chromium.org/1122153002 Cr-Commit-Position: refs/heads/master@{#332080}
* base: Remove the remaining usage of GG_(U)INTn_C macros.tfarina2015-05-184-5/+7
| | | | | | | | | | | | | | According to comment in base/port.h, in Chromium, we force-define __STDC_CONSTANT_MACROS, so we can just use the regular (U)INTn_C macros from <stdint.h>. BUG=138542 TEST=base_unittests R=danakj@chromium.org Review URL: https://codereview.chromium.org/1128203010 Cr-Commit-Position: refs/heads/master@{#330440}
* [RELAND] Fixit: Factor out common base::Time* math operator overloads.miu2015-05-103-219/+171
| | | | | | | | | | | | | | | | This relands https://codereview.chromium.org/1122443004 with a landmine to clobber the iOS builds. This is necessary because Xcode's logic for determining that base/time/time.h changed is faulty and is preventing modules dependent on it from being rebuilt. Revert history: https://codereview.chromium.org/1125283003 BUG=467417,485435 TBR=stuartmorgan@chromium.org Review URL: https://codereview.chromium.org/1131923005 Cr-Commit-Position: refs/heads/master@{#329060}
* Revert of Revert of Revert of Fixit: Factor out common base::Time* math ↵gcasto2015-05-073-171/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operator overloads. (patchset #1 id:1 of https://codereview.chromium.org/1128273004/) Reason for revert: Still breaks iOS bots. Tracking at crbug.com/485435. Original issue's description: > Revert of Revert of Fixit: Factor out common base::Time* math operator overloads. (patchset #1 id:1 of https://codereview.chromium.org/1130953002/) > > Reason for revert: > iOS_Device builder was not rebuilding certain modules dependent on changes in base::Time. http://crbug.com/485435 > > Original issue's description: > > Revert of Fixit: Factor out common base::Time* math operator overloads. (patchset #2 id:40001 of https://codereview.chromium.org/1122443004/) > > > > Reason for revert: > > Broke iOS build. > > > > http://build.chromium.org/p/chromium.mac/builders/iOS_Device/builds/5621/steps/compile/logs/stdio > > > > Original issue's description: > > > Fixit: Factor out common base::Time* math operator overloads. > > > > > > This is part 1 of a 2-part change to fork base::TimeTicks into three > > > type-checked time classes (TimeTicks + ThreadTicks + TraceTicks). The > > > forking of TimeTicks will ensure values from different clocks are not > > > erroneously being mixed together when doing time math. > > > > > > In this change, the identical comparison and math operator overloads > > > found in base::Time and base::TimeTicks are being factored-out into a > > > templated base class. In a following change, this base class will also > > > be used to de-dupe this common functionality in the two new time > > > classes. > > > > > > BUG=467417 > > > > > > Committed: https://crrev.com/7ca717095b4758cb76e53e904b775852e46d646d > > > Cr-Commit-Position: refs/heads/master@{#328696} > > > > TBR=thestig@chromium.org,miu@chromium.org > > NOPRESUBMIT=true > > NOTREECHECKS=true > > NOTRY=true > > BUG=467417 > > > > Committed: https://crrev.com/a365825583412c355a449274bec70e41e992ffd7 > > Cr-Commit-Position: refs/heads/master@{#328706} > > TBR=thestig@chromium.org,ksakamoto@chromium.org > NOPRESUBMIT=true > BUG=467417,485435 > > Committed: https://crrev.com/59fca1cd30487a013b942acf9d660dfcc639e25a > Cr-Commit-Position: refs/heads/master@{#328843} TBR=thestig@chromium.org,ksakamoto@chromium.org,smut@chromium.org,miu@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=467417,485435 Review URL: https://codereview.chromium.org/1125283003 Cr-Commit-Position: refs/heads/master@{#328864}
* Revert of Revert of Fixit: Factor out common base::Time* math operator ↵miu2015-05-073-219/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | overloads. (patchset #1 id:1 of https://codereview.chromium.org/1130953002/) Reason for revert: iOS_Device builder was not rebuilding certain modules dependent on changes in base::Time. http://crbug.com/485435 Original issue's description: > Revert of Fixit: Factor out common base::Time* math operator overloads. (patchset #2 id:40001 of https://codereview.chromium.org/1122443004/) > > Reason for revert: > Broke iOS build. > > http://build.chromium.org/p/chromium.mac/builders/iOS_Device/builds/5621/steps/compile/logs/stdio > > Original issue's description: > > Fixit: Factor out common base::Time* math operator overloads. > > > > This is part 1 of a 2-part change to fork base::TimeTicks into three > > type-checked time classes (TimeTicks + ThreadTicks + TraceTicks). The > > forking of TimeTicks will ensure values from different clocks are not > > erroneously being mixed together when doing time math. > > > > In this change, the identical comparison and math operator overloads > > found in base::Time and base::TimeTicks are being factored-out into a > > templated base class. In a following change, this base class will also > > be used to de-dupe this common functionality in the two new time > > classes. > > > > BUG=467417 > > > > Committed: https://crrev.com/7ca717095b4758cb76e53e904b775852e46d646d > > Cr-Commit-Position: refs/heads/master@{#328696} > > TBR=thestig@chromium.org,miu@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=467417 > > Committed: https://crrev.com/a365825583412c355a449274bec70e41e992ffd7 > Cr-Commit-Position: refs/heads/master@{#328706} TBR=thestig@chromium.org,ksakamoto@chromium.org NOPRESUBMIT=true BUG=467417,485435 Review URL: https://codereview.chromium.org/1128273004 Cr-Commit-Position: refs/heads/master@{#328843}
* Revert of Fixit: Factor out common base::Time* math operator overloads. ↵ksakamoto2015-05-073-171/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #2 id:40001 of https://codereview.chromium.org/1122443004/) Reason for revert: Broke iOS build. http://build.chromium.org/p/chromium.mac/builders/iOS_Device/builds/5621/steps/compile/logs/stdio Original issue's description: > Fixit: Factor out common base::Time* math operator overloads. > > This is part 1 of a 2-part change to fork base::TimeTicks into three > type-checked time classes (TimeTicks + ThreadTicks + TraceTicks). The > forking of TimeTicks will ensure values from different clocks are not > erroneously being mixed together when doing time math. > > In this change, the identical comparison and math operator overloads > found in base::Time and base::TimeTicks are being factored-out into a > templated base class. In a following change, this base class will also > be used to de-dupe this common functionality in the two new time > classes. > > BUG=467417 > > Committed: https://crrev.com/7ca717095b4758cb76e53e904b775852e46d646d > Cr-Commit-Position: refs/heads/master@{#328696} TBR=thestig@chromium.org,miu@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=467417 Review URL: https://codereview.chromium.org/1130953002 Cr-Commit-Position: refs/heads/master@{#328706}
* Fixit: Factor out common base::Time* math operator overloads.miu2015-05-073-219/+171
| | | | | | | | | | | | | | | | | | | This is part 1 of a 2-part change to fork base::TimeTicks into three type-checked time classes (TimeTicks + ThreadTicks + TraceTicks). The forking of TimeTicks will ensure values from different clocks are not erroneously being mixed together when doing time math. In this change, the identical comparison and math operator overloads found in base::Time and base::TimeTicks are being factored-out into a templated base class. In a following change, this base class will also be used to de-dupe this common functionality in the two new time classes. BUG=467417 Review URL: https://codereview.chromium.org/1122443004 Cr-Commit-Position: refs/heads/master@{#328696}
* Removed obsolete float_util.h as VS2013 supports standards well enough.mateuszs2015-04-241-2/+2
| | | | | | | | BUG= Review URL: https://codereview.chromium.org/1076443002 Cr-Commit-Position: refs/heads/master@{#326781}
* Clamp TimeDelta operations that overflow.rvargas2015-03-213-18/+137
| | | | | | | | | BUG=466445 TEST=base_unittests Review URL: https://codereview.chromium.org/1000393004 Cr-Commit-Position: refs/heads/master@{#321687}
* Move time constants to base::Timeqiankun.miao2015-03-171-1/+4
| | | | | | | | BUG=412254 Review URL: https://codereview.chromium.org/1008333002 Cr-Commit-Position: refs/heads/master@{#320875}
* base: Fix/add header #ifndef guards.danakj2015-03-104-12/+12
| | | | | | | | | | | | | | | | Header guards should be defined based on the path and file name of the header file. Some headers have it wrong, some are missing the guards, and some just have the matching comment wrong. R=Nico BUG=464816 Committed: https://crrev.com/301b392761fd8f66f3a701ab1dd011c6e7a55e19 Cr-Commit-Position: refs/heads/master@{#319722} Review URL: https://codereview.chromium.org/985003004 Cr-Commit-Position: refs/heads/master@{#319793}
* base: Use more specific CHECK macros for comparisons.danakj2015-03-091-2/+2
| | | | | | | | | | | | | | | Prefer DCHECK_EQ(a, b) over DCHECK(a == b) when possible as this provides more data on a failure. Similar for other operators such as >=, <, !=, etc. This also applies to CHECK, EXPECT, and ASSERT macros. R=Nico BUG=464816 Review URL: https://codereview.chromium.org/985723003 Cr-Commit-Position: refs/heads/master@{#319751}
* Revert of base: Fix/add header #ifndef guards. (patchset #2 id:20001 of ↵bnc2015-03-094-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/985003004/) Reason for revert: This seems to be causing tree closing compile failure https://build.chromium.org/p/chromium/builders/Android/builds/36135/steps/compile/logs/stdio. Original issue's description: > base: Fix/add header #ifndef guards. > > Header guards should be defined based on the path and file name of the > header file. Some headers have it wrong, some are missing the guards, > and some just have the matching comment wrong. > > R=Nico > BUG=464816 > > Committed: https://crrev.com/301b392761fd8f66f3a701ab1dd011c6e7a55e19 > Cr-Commit-Position: refs/heads/master@{#319722} TBR=thakis@chromium.org,danakj@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=464816 Review URL: https://codereview.chromium.org/989343002 Cr-Commit-Position: refs/heads/master@{#319728}
* base: Fix/add header #ifndef guards.danakj2015-03-094-12/+12
| | | | | | | | | | | | | Header guards should be defined based on the path and file name of the header file. Some headers have it wrong, some are missing the guards, and some just have the matching comment wrong. R=Nico BUG=464816 Review URL: https://codereview.chromium.org/985003004 Cr-Commit-Position: refs/heads/master@{#319722}
* base::Time multiplicative operator overloadingmichaeln2015-02-232-20/+82
| | | | | | Review URL: https://codereview.chromium.org/945143002 Cr-Commit-Position: refs/heads/master@{#317653}
* [DOMStorage] Rate limiting writes to disk.michaeln2015-02-202-0/+17
| | | | | | | | | | | Given access patterns that are just wrong, local & session storage can write many gigabytes per day or keep the disk perpetually spun up. To avoid excessive IO, we apply limits to the amount of data being written and the frequency of writes to address both kinds of 'bad' behaviors. TBR=rvargas BUG=176727 Review URL: https://codereview.chromium.org/896643002 Cr-Commit-Position: refs/heads/master@{#317424}
* Add a base::TimeTicks::SnappedToNextTick methodbrianderson2015-02-133-0/+78
| | | | | | | | | | | | | | | | | | | | | | Snapping a timestamp to the next phase (i.e. vsync) is a common calculation we'll want to make in different parts of the code. Right now, it's only done in DelayBasedTimeSource. However, this patch moves the calculation to base in anticipation that it will be used in a couple other places for latency calculations soon. It's very easy to get wrong, given the number of bugs we've fixed while the logic was in DelayBasedTimeSource, so having a single shared implementation will avoid duplicating mistakes. BUG=360844 Review URL: https://codereview.chromium.org/913133006 Cr-Commit-Position: refs/heads/master@{#316093}
* Replaces instances of the deprecated TimeTicks::HighResNow() with ↵charliea2015-01-266-25/+16
| | | | | | | | | | TimeTicks::Now(). BUG= Review URL: https://codereview.chromium.org/864943002 Cr-Commit-Position: refs/heads/master@{#313084}
* [Windows] One TimeTicks clock: efficient/reliable high-res, with low-res ↵miu2015-01-146-256/+266
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fallback. This change resolves a critical issue where two different clocks' values were being mixed in computations involving TimeTicks for ~32% of users on Windows. The solution is to force the use of a single clock for TimeTicks::Now() and HighResNow(). In other words, we're moving towards a world where the TimeTicks type should guarantee all time values are on the same timeline. New behavior: On systems where QPC is reliable AND efficient, Now() will simply use the QPC clock. This is consistent with how Now() behaves on the Mac and POSIX platforms. However, if QPC is working but is inefficient, Now() will use the low-res clock. Finally, like before, if the QPC is not working on the current system, Now() will use the low-res clock. NowFromSystemTraceTime() will always use the QPC clock if it is working, just as before, and regardless of whether it is expensive to use. This is to ensure tracing data remains useful. When QPC uses either HPET or ACPI PM as a clock source, online literature suggests clock sampling will be ~20 to ~40 times as costly (about 1.2 to 2.4us per call). Note: From discussion with stakeholders, there is a concern this change will increase latency and jitter in the compositor pipeline on the affected Windows machines. Future changes will take alternate approaches to resolve these problems. Note 2: This change minimizes TimeTicks API changes, in favor of future clean-up changes. BUG=396384,435931,439656 Review URL: https://codereview.chromium.org/797893003 Cr-Commit-Position: refs/heads/master@{#311414}
* Clean-up: Remove base::TimeTicks::UnprotectedNow().miu2015-01-062-11/+0
| | | | | | | | | | | | | | | | | | This method was added in r222396: https://chromiumcodereview.appspot.com/23147002 However, with the current implementation of base::TimeTicks::Now(), this logic appears to be bogus. The comment in TrackedTime::Now() thinks this method provides a lock-free execution of the timeGetTime() function, but that is only the case on older systems without an efficient QPC implementation. Furthermore, for those older systems, the overhead in processing for the "rollover-protected" timestamp is negligible (~20ns, according to benchmarking; compare this to the 1.0 ms to 15.6 ms precision of the clock). Review URL: https://codereview.chromium.org/829113002 Cr-Commit-Position: refs/heads/master@{#310039}
* Standardize usage of virtual/override/final specifiers in base/.dcheng2014-12-232-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Google C++ style guide states: Explicitly annotate overrides of virtual functions or virtual destructors with an override or (less frequently) final specifier. Older (pre-C++11) code will use the virtual keyword as an inferior alternative annotation. For clarity, use exactly one of override, final, or virtual when declaring an override. To better conform to these guidelines, the following constructs have been rewritten: - if a base class has a virtual destructor, then: virtual ~Foo(); -> ~Foo() override; - virtual void Foo() override; -> void Foo() override; - virtual void Foo() override final; -> void Foo() final; This patch was automatically generated. The clang plugin can generate fixit hints, which are suggested edits when it is 100% sure it knows how to fix a problem. The hints from the clang plugin were applied to the source tree using the tool in https://codereview.chromium.org/598073004. Several formatting edits by clang-format were manually reverted, due to mangling of some of the more complicate IPC macros. BUG=417463 Review URL: https://codereview.chromium.org/804533005 Cr-Commit-Position: refs/heads/master@{#309527}
* Use higher precision to store the login database's date_created field.erikchen2014-11-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | When a password is created or updated, its creation_date is saved in the login database with precision seconds. The same data is stored in the password sync server with precision microseconds. As a result, the two passwords always appear to differ. I've changed the code so that the creation_date is stored in the login database with precision microseconds, and I've created a migration to update the existing login database entries. Prior to the migration, creation_date was a time_t, which has precision seconds and counts from the UTC epoch. After the migration, creation_date has precision microseconds, and counts from Chrome's platform independent epoch. Note that the very first time passwords are all synced, they will still appear to differ since the login database lost 6 decimal places of precision. This CL makes it so that on the second sync (and subsequent syncs), the passwords will no longer differ. BUG=408800 Review URL: https://codereview.chromium.org/702893005 Cr-Commit-Position: refs/heads/master@{#303783}
* Add logging support for base::Time* types.ricea2014-10-293-3/+148
| | | | | | | | | | | | Define operator<<(ostream&,Time) to permit Time, TimeDelta and TimeTicks types to be used in logging assertions such as DCHECK_EQ(). BUG=425941 TEST=base_unittests Review URL: https://codereview.chromium.org/669083002 Cr-Commit-Position: refs/heads/master@{#301815}
* Standardize usage of virtual/override/final in base/dcheng2014-10-212-4/+4
| | | | | | | | | BUG=417463 TBR=danakj@chromium.org Review URL: https://codereview.chromium.org/668783004 Cr-Commit-Position: refs/heads/master@{#300447}
* replace OVERRIDE and FINAL with override and final in base/mostynb2014-10-074-4/+4
| | | | | | | | BUG=417463 Review URL: https://codereview.chromium.org/611153004 Cr-Commit-Position: refs/heads/master@{#298520}
* Fix more disabled MSVC warnings, base/ edition.pkasting2014-10-013-16/+13
| | | | | | | | | | | | Mostly this fixes cases of "possible value truncation", usually by inserting explicit typecasts. BUG=81439 TEST=none Review URL: https://codereview.chromium.org/596103002 Cr-Commit-Position: refs/heads/master@{#297723}
* Avoid 64-bit divide when sampling timestampbrianderson2014-09-291-1/+1
| | | | | | | | | | | | | | | | | On some lower-end platforms, 64-bit integer division is emulated or is significantly slower than 32-bit integer division even if not emulated. When converting ns to us in TimeTicks::Now(), we don't need the range of a 64-bit integer because we are starting with a 32-bit integer and making it smaller. There is no need to convert it to 64-bits before the division. BUG=none Review URL: https://codereview.chromium.org/600013003 Cr-Commit-Position: refs/heads/master@{#297287}
* Reland: Issue 446203002: Initialize the now_function to the ↵Fadi Meawad2014-09-052-38/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | HighResNowWrapper in case High Res is supported https://codereview.chromium.org/446203002/ The reland avoids using a static initializer for now_function, it initializes the function pointer on the first call instead. I incorporated maruel@'s suggestions. jam for chrome/browser/ content/app/ willchan,maruel for base/time/ BUG=400627 R=cpu@chromium.org, jam@chromium.org, maruel@chromium.org, thakis@chromium.org Committed: https://chromium.googlesource.com/chromium/src/+/a7c8e5e3411d6a3d32f4e1a61f8baa3e438fee52 Review URL: https://codereview.chromium.org/530293002 Cr-Commit-Position: refs/heads/master@{#293555}
* fix for high resolution timer on windows.cpu2014-09-051-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | The CLs here https://codereview.chromium.org/489793003 and here https://codereview.chromium.org/395913006 In isolation look correct but taken together cause a overflow or underflow bug. Basically the message loop was calling Time::ActivateHighResolutionTimer(false) all the time (or very often) so the g_high_res_timer_count was underflowing or overflowing. Now messageloop only calls ActivateHighResolutionTimer in a balanced way. This can make the base_unittests fail as well with --gtest_filter=MessageLoopTest.HighResolutionTimer BUG=153139 TEST=included, see bug for manual testing. Review URL: https://codereview.chromium.org/541203002 Cr-Commit-Position: refs/heads/master@{#293434}
* Revert of Initialize the now_funciton to the HighResNowWrapper in case High ↵fmeawad2014-08-282-20/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Res is supported (patchset #7 of https://codereview.chromium.org/446203002/) Reason for revert: It causes a Canary crash https://code.google.com/p/chromium/issues/detail?id=408354 The added static initializer causes a crash in libpeerconnetion used by WebRTC Fix to reland: remove static initializer. Original issue's description: > We have noticed a clock shift when QPC was deployed. It shows as a regression on the perf bots > https://chromeperf.appspot.com/report?masters=ChromiumPerf&bots=chromium-rel-win8-dual&tests=startup.warm.dirty.blank_page%2Fwindow_display_time&rev=286928 > > It is not a real regression, the initial_time and initial_ticks are not properly initialized when switching to HighResolution (i.e. QPC). > This CL initializes the now_function to the HighResNowWrapper instead of setting it to RolloverProtectedNow then to the HighResNowWrapper. > > By doing that, we avoid getting an incorrect initial_time and initial_ticks using the RolloverProtectedNow and avoid having to reinitialize. > > BUG=158234 > > Committed: https://chromium.googlesource.com/chromium/src/+/10c40c221c314e41add0a5b4df1ee7467681a430 TBR=jar@chromium.org,willchan@chromium.org,maruel@chromium.org,thakis@chromium.org,jam@chromium.org,cpu@chromium.org NOTREECHECKS=true NOTRY=true BUG=158234 Review URL: https://codereview.chromium.org/516693002 Cr-Commit-Position: refs/heads/master@{#292288}
* Fix logic on high Windows resolution timer and havecpu2014-08-272-49/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | two possible period values for timeBeginPeriod and timeEndPeriod. Currently while on battery we disable calls to timeBeginPeriod which make the windows timers have 15ms resolution. This change makes it so when EnableHighResolutionTimer(true) which is on AC power the timer is 1ms and EnableHighResolutionTimer(false) is 4ms. This should provide significant power savings while meeting some timer resolution requirements needed by the GPU compositor. But also this CL fixes the following: EnableHighResolutionTimer() and ActivateHighResolutionTimer() are pretty broken. This CL fixes most issues: 1- The existing logic fails to account that EnableHighResolutionTimer can be called while the browser is running 2- All related functions need to be thread safe. 3- ActivateHighResolutionTimer was buggy. BUG=153139 Review URL: https://codereview.chromium.org/489793003 Cr-Commit-Position: refs/heads/master@{#292094}
generated by cgit v1.1 at 2024-07-02 02:08:18 +0000