- 12 Feb, 2018 1 commit
-
-
Junliang Yan authored
some time the output of these two could be the same if machine is fast enough. Change-Id: I1d9c0191657abae3d053517d45059065df2d44dc Reviewed-on: https://chromium-review.googlesource.com/911873Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#51247}
-
- 19 Dec, 2017 1 commit
-
-
Ulan Degenbaev authored
Background tasks read this flag, which creates a data race. This patch works around the data races by making the access to the flag atomic. The actual fix will be to not mutate the flag. Bug: chromium:794911 Change-Id: Idcf03b7a1037e876036918418ce989b420784428 Reviewed-on: https://chromium-review.googlesource.com/834508Reviewed-by:
Fadi Meawad <fmeawad@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#50215}
-
- 30 Nov, 2017 2 commits
-
-
Ulan Degenbaev authored
Bug: chromium:758183 Change-Id: If43122140626207e3f972ccb7d048e012db3ed02 Reviewed-on: https://chromium-review.googlesource.com/796771 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49749}
-
Ulan Degenbaev authored
Currently RuntimeCallStats stores CounterIds as inner pointers. This patch replaces them with enums and removes static table. Bug: chromium:758183 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icb4030fc3ad3dd02e9c2648ce7c43b6f2d47fa9d Reviewed-on: https://chromium-review.googlesource.com/796477Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#49743}
-
- 14 Nov, 2017 1 commit
-
-
Camillo Bruni authored
This CL adds a very crude unittest to check that RuntimeCallStats work correctly with api callbacks present. This currently doesn't check that all parent timers (namely FunctionCallback) are handled properly. Drive-by-Fix: - Use Microseconds for all RCS timer tests - Add TestWithContext::SetGlobalProperty helper - Use explicit v8:: prefix in test-utils.{h,cc} Change-Id: I054e78abca0b87a3b9e07d3b06cccdad15403bae Reviewed-on: https://chromium-review.googlesource.com/766429 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#49348}
-
- 10 Nov, 2017 1 commit
-
-
Camillo Bruni authored
- Implement exchangeable timer clock for RuntimeCallStats for testing - Rewrite RuntimeCAllStatsTest to overwrite the default RCS timer This gets rid of the previous flakiness for these tests due to using the real platform timer. Bug: v8:5677 Change-Id: Iff312c7f79ab97407ba1c0c2c72fb0b35a5efdf1 Reviewed-on: https://chromium-review.googlesource.com/760416Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#49285}
-
- 08 Jun, 2017 1 commit
-
-
kschimpf authored
This CL takes advantage of the fact that StatsCounter is now local to the Counters class. This includes: 1) Method StatsTable::SetCreateHistogramFunction() was only called in one spot (in api.cc), which also called Counters::ResetHistograms() and Counters::InitializeHistorgram(). InitializeHistogram can be folded into Histogram.Reset(). 2) Since Histogram::Reset() now regenerats the histogram, we no longer need the field lookup_done_. Therefore there is no longer a race between updating ptr_ and lookup_done_, making the Histogram class thread safe. 3) Made the constructors of several classes private (except for class Counters), minimizing the scope that they are used. When the couldn't be moved, add comment that they were public only for test cases. 4) Removed the need for a mutex lock on StatsCounter::Reset(), since it is now guaranteed to only be called when StatsTable::SetCounterFunction() is called. BUG=v8:6361 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng Review-Url: https://codereview.chromium.org/2918703002 Cr-Commit-Position: refs/heads/master@{#45791}
-
- 24 Nov, 2016 1 commit
-
-
cbruni authored
RuntimeTimerScopes always subtract their own time from the parent timer's counter to properly account for the own time. Once a scope is destructed it adds it own timer to the current active counter. However, if the current counter is changed with CorrectCurrentCounterId we will attribute all the subtimers to the previous counter, and add the own time to the new counter. This way it is possible to end up with negative times in certain counters but the overall would still be correct. BUG= Review-Url: https://codereview.chromium.org/2511093002 Cr-Commit-Position: refs/heads/master@{#41254}
-
- 23 Nov, 2016 2 commits
-
-
machenbach authored
Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters. (patchset #15 id:320001 of https://codereview.chromium.org/2511093002/ ) Reason for revert: The test is very flaky on the bots, e.g.: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/17031 https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/14776 Original issue's description: > [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters > > RuntimeTimerScopes always subtract their own time from the parent timer's > counter to properly account for the own time. Once a scope is destructed it > adds it own timer to the current active counter. However, if the current > counter is changed with CorrectCurrentCounterId we will attribute all the > subtimers to the previous counter, and add the own time to the new counter. > This way it is possible to end up with negative times in certain counters but > the overall would still be correct. > > BUG= > > Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8 > Committed: https://crrev.com/491651792d7818aed04eaeffb9890b5a309b543e > Cr-Original-Commit-Position: refs/heads/master@{#41142} > Cr-Commit-Position: refs/heads/master@{#41214} TBR=ishell@chromium.org,fmeawad@chromium.org,lpy@chromium.org,cbruni@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2526843002 Cr-Commit-Position: refs/heads/master@{#41229}
-
cbruni authored
RuntimeTimerScopes always subtract their own time from the parent timer's counter to properly account for the own time. Once a scope is destructed it adds it own timer to the current active counter. However, if the current counter is changed with CorrectCurrentCounterId we will attribute all the subtimers to the previous counter, and add the own time to the new counter. This way it is possible to end up with negative times in certain counters but the overall would still be correct. BUG= Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8 Review-Url: https://codereview.chromium.org/2511093002 Cr-Original-Commit-Position: refs/heads/master@{#41142} Cr-Commit-Position: refs/heads/master@{#41214}
-
- 21 Nov, 2016 2 commits
-
-
cbruni authored
Revert of [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters. (patchset #10 id:180001 of https://codereview.chromium.org/2511093002/ ) Reason for revert: Wronged it even more. Original issue's description: > [counters] RuntimeStats: fix wrong bookkeeping when dynamically changing counters > > RuntimeTimerScopes always subtract their own time from the parent timer's > counter to properly account for the own time. Once a scope is destructed it > adds it own timer to the current active counter. However, if the current > counter is changed with CorrectCurrentCounterId we will attribute all the > subtimers to the previous counter, and add the own time to the new counter. > This way it is possible to end up with negative times in certain counters but > the overall would still be correct. > > BUG= > > Committed: https://crrev.com/f6c74d964d9387df4bed3d8c1ded51eb9e8aa6e8 > Cr-Commit-Position: refs/heads/master@{#41142} TBR=ishell@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2519073002 Cr-Commit-Position: refs/heads/master@{#41150}
-
cbruni authored
RuntimeTimerScopes always subtract their own time from the parent timer's counter to properly account for the own time. Once a scope is destructed it adds it own timer to the current active counter. However, if the current counter is changed with CorrectCurrentCounterId we will attribute all the subtimers to the previous counter, and add the own time to the new counter. This way it is possible to end up with negative times in certain counters but the overall would still be correct. BUG= Review-Url: https://codereview.chromium.org/2511093002 Cr-Commit-Position: refs/heads/master@{#41142}
-
- 11 May, 2015 1 commit
-
-
wingo authored
R=svenpanne@chromium.org LOG=N BUG= Review URL: https://codereview.chromium.org/1128043002 Cr-Commit-Position: refs/heads/master@{#28337}
-
- 07 May, 2015 1 commit
-
-
ulan authored
This introduces V8.MemoryHeapCommitted and V8.MemoryHeapUsed histograms. In contrast to the existing memory histograms, the new histograms are uniform in time, i.e. their samples happen at regular time intervals. The --histogram-interval specifies the length of the interval. We implement this by linearly interpolating memory stats between GC and idle notification events. BUG=chromium:485472 LOG=NO Review URL: https://codereview.chromium.org/1125683004 Cr-Commit-Position: refs/heads/master@{#28292}
-