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

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

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

Review URL: http://codereview.chromium.org/1514006

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4317 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

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

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

Review URL: http://codereview.chromium.org/1049003

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@4162 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

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