- 05 Sep, 2013 1 commit
-
-
yurys@chromium.org authored
Renamed StartDequeue -> Peek, FinishDequeue -> Remove. BUG=None R=bmeurer@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/23686006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16549 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 Aug, 2013 1 commit
-
-
bmeurer@chromium.org authored
This renames the existing V8_ALIGNAS() to V8_ALIGNED(), and introduces V8_ALIGNAS(type, alignment) which aligns according to the type and falls back to aligning according to alignment. Also use __attribute__((aligned(n))) instead of __attribute__((__aligned__(n))). R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/22999052 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16318 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Aug, 2013 2 commits
-
-
yurys@chromium.org authored
BUG=None R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/23361023 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16285 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
The new implementation: * uses MemoryBarriers to make sure up-to-date data is accessed on both producer and consumer threads * will not allow to overwrite records * doesn't have notion of chunks, instead each entry is aligned on the cache line boundaries BUG=v8:2814 R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/22849002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16284 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Jul, 2013 2 commits
-
-
yurys@chromium.org authored
BUG=None TBR=yangguo@chromium.org Review URL: https://codereview.chromium.org/19778003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15753 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
This change fixes data race described in the bug by adding Acquire_Load to SamplingCircularQueue::StartDequeue and Acquire_Store to SamplingCircularQueue::Enqueue. Also the queue implementation imposed a constraint on the records it stored: the first AtomicWord in each record was a marker. For that purpose TickSampleEventRecord had filter field of type int. This approach is error prone, e.g. on x64 sizeof(AtomicWord) is 8 while sizeof(int) is 4. Moreover the queue needs such marker only at the beginning of chunk. I changed the queue so that it stores the marker explicitly as the first Cell in chunk and removed the filter field. BUG=251218 R=loislo@chromium.org, yangguo@chromium.org Review URL: https://codereview.chromium.org/19642002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15750 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Mar, 2013 1 commit
-
-
yurys@chromium.org authored
This reverts commit r13735 as CPU profiler data is inaccurate after that change. BUG=v8:2571 Review URL: https://codereview.chromium.org/12592002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13851 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 Feb, 2013 1 commit
-
-
yurys@chromium.org authored
The patch is based on the previous one that was rolled out: https://code.google.com/p/v8/source/detail?r=12985 On Linux sampling for CPU profiler is initiated on the profiler event processor thread, other platforms to follow. CPU profiler continues to use SamplingCircularQueue, we will replave it with a single sample buffer when Mac and Win ports support profiling on the event processing thread. When --prof option is specified profiling is initiated either on the profiler event processor thread if CPU profiler is on or on the SignalSender thread as it used to if no CPU profiles are being collected. ProfilerEventsProcessor::ProcessEventsAndDoSample now waits in a tight loop, processing collected samples until sampling interval expires. To save CPU resources I'm planning to change that to use nanosleep as only one sample is expected in the queue at any point. BUG=v8:2364 Review URL: https://codereview.chromium.org/12321046 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13735 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 May, 2010 1 commit
-
-
mikhail.naganov@gmail.com authored
I changed the implementation of a queue between the VM and processor thread to be unbounded and lock-free, using Herb Sutter's example from DDJ article: http://www.ddj.com/high-performance-computing/210604448 This had brought back profiling overhead to a minimum for the page from Chromium's issue 16184. BUG=714 Review URL: http://codereview.chromium.org/2091019 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4706 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Mar, 2010 1 commit
-
-
mikhail.naganov@gmail.com authored
Review URL: http://codereview.chromium.org/1514006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4317 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Mar, 2010 1 commit
-
-
mikhail.naganov@gmail.com authored
This is for the case of Linux, where sampling is done using SIGPROF signal handler which is executed in the context of an interrupted thread. In this case, my previous implementation with TLS doesn't work. Review URL: http://codereview.chromium.org/1138004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4207 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Mar, 2010 3 commits
-
-
mikhail.naganov@gmail.com authored
TBR=sgjesse@chromium.org Review URL: http://codereview.chromium.org/979005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4164 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
fschneider@chromium.org authored
Review URL: http://codereview.chromium.org/1049003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4162 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
mikhail.naganov@gmail.com authored
Circular queues serve as a transport for communicating between VM, stack sampler and analyzer threads. Logging requirements for VM and stack sampler are completely different, that's why I introduced two different versions of CQs. Review URL: http://codereview.chromium.org/1047002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4159 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-