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
Thread class was receiving an isolate parameter by default.
This approact violates the assumption that only VM threads
can have an associated isolate, and can lead to troubles,
because accessing the same isolate from different threads
leads to race conditions.
This was found by investigating mysterious failures of the
CPU profiler layout test on Linux Chromium. As almost all
threads were associated with some isolate, the sampler was
trying to sample them.
As a side effect, we have also fixed the DebuggerAgent test.
Thanks to Vitaly for help in fixing isolates handling!
R=vitalyr@chromium.org
BUG=none
TEST=none
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8259 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
