Skip to content

V
V8
Switch branch/tag
  1. 14 Apr, 2015 3 commits
  3. 08 Apr, 2015 1 commit
  5. 07 Apr, 2015 1 commit
  7. 17 Mar, 2015 1 commit
  9. 09 Mar, 2015 1 commit
    • loislo's avatar
      CpuProfiler: fix for GetDeoptReason code. · 66ab309e
      loislo authored 
      The original code always returned the first entry from RelocInfo that matched with
bailout_id. But we may have a few different deopt reasons for one bailout_id.
So we need to get the one which matches with a particular call from JumpTable.

We can do this by checking not 'target_address' (it maps to bailout_id)
but 'from' address which maps to a particular JumpTable entry.

The test was reworked so it tests identical functions against different reasons.

BUG=chromium:452067
LOG=n

Review URL: https://codereview.chromium.org/984773003

Cr-Commit-Position: refs/heads/master@{#27076}
      66ab309e
  11. 27 Feb, 2015 1 commit
  13. 20 Feb, 2015 1 commit
    • loislo's avatar
      CpuProfiler: eliminate cpu-profiler dependency from heap-inl.h · 8ba89cce
      loislo authored 
      We accessed to cpu_profiler for tracking SharedFunctionInfo objects movements and used their addresses for generating function_id. Actually we could replace the manually generated shared_id by the pair script_id + position. In this case we can drop SharedFunctionInfo events support from cpu_profiler and remove the dependency.

BTW GetCallUid was used as an unique identifier of the function on the front-end side. Actually it is a hash which might not be unique. So I renamed GetCallUid with GetHash and implemented GetFunctionId method.

BUG=452067
LOG=n

Review URL: https://codereview.chromium.org/941973002

Cr-Commit-Position: refs/heads/master@{#26775}
      8ba89cce
  15. 10 Feb, 2015 1 commit
    • loislo's avatar
      Propagate DeoptInfo to cpu-profiler · 86cae163
      loislo authored 
      1) Deoptimizer::Reason was replaced with Deoptimizer::DeoptInfo
because it also has raw position. Also the old name clashes with DeoptReason enum.

2) c_entry_fp assignment call was added to EntryGenerator::Generate
So we can calculate sp and have a chance to record the stack for the deopting function.
btw it makes the test stable.

3) new kind of CodeEvents was added to cpu-profiler

4) GetDeoptInfo method was extracted from PrintDeoptLocation.
So it could be reused in cpu profiler.

BUG=452067
LOG=n

Review URL: https://codereview.chromium.org/910773002

Cr-Commit-Position: refs/heads/master@{#26545}
      86cae163
  17. 07 Oct, 2014 1 commit
  19. 05 Aug, 2014 1 commit
  21. 30 Jun, 2014 1 commit
  23. 05 Jun, 2014 1 commit
  25. 03 Jun, 2014 1 commit
  27. 22 May, 2014 1 commit
  29. 29 Apr, 2014 1 commit
  31. 10 Jan, 2014 1 commit
  33. 18 Dec, 2013 1 commit
  35. 10 Oct, 2013 1 commit
  37. 06 Sep, 2013 1 commit
    • yurys@chromium.org's avatar
      Check if timeout has expired after processing each sample · 43780dbd
      yurys@chromium.org authored 
      To avoid long intervals between taking samples due to processing all accumulated samples at once, the samples are processed one by one and we check if the sampling interval has elapsed after each step rather than after processing all the samples in the queue.

This is a modified version of r16549 whith a fix for test flakiness. The test flakiness introduced by the previous version of this changed was fixed by changing return type of ProfilerEventsProcessor::ProcessOneSample from bool to enum with 3 options. In the main profiling loop we decide that the next code event should be processed when sample with a greater ordinal number is encountered. When processing remaining samples we shouldn't wait for more samples and if the samples queue is empty we just process next code event.

BUG=v8:2814,v8:2871
R=bmeurer@chromium.org, loislo@chromium.org

Review URL: https://codereview.chromium.org/23455036

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16564 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      43780dbd
  39. 05 Sep, 2013 2 commits
  41. 04 Sep, 2013 1 commit
  43. 29 Aug, 2013 3 commits
  45. 28 Aug, 2013 6 commits
  47. 26 Aug, 2013 1 commit
    • yurys@chromium.org's avatar
      Support higher CPU profiler sampling rate on posix systems · 4db1f475
      yurys@chromium.org authored 
      New flag is added that allows to specify CPU profiler sampling rate in microseconds as command line argument. It was tested to work fine with 100us interval(currently it is 1ms). Default values are kept the same as in the current implementation. The new implementation is enabled only on POSIX platforms which use signals to collect samples. Other platforms that pause thread being sampled are to follow.

SIGPROF signals are now sent on the profiler event processor thread to make sure that the processing thread does fall far behind the sampling.

The patch is based on the previous one that was rolled out in r13851. The main difference is that the circular queue is not modified for now.

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 probably replace 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 be 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:2814
R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/21101002

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16310 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      4db1f475
  49. 23 Aug, 2013 1 commit
  51. 07 Aug, 2013 1 commit
  53. 26 Jul, 2013 1 commit
    • loislo@chromium.org's avatar
      Logger: introduce abstract interface for CodeEvent listeners. · 141ada02
      loislo@chromium.org authored 
      New abstract class CodeEventListener was created.

CodeEventLogger which is the base class for Jit, LowLevel
and CodeAddressMap loggers was inherited from CodeEventListener.

CodeAddressMap class was moved to serializer.cc because serializer is the only user for it. Actually it collects code names and pushes them to the standard log as SnapshotCodeNameEvent. So I extracted this code into separate function CodeNameEvent. It happens that this method works only when Serializer serializes an object. So I added direct log call there.

CodeEventLogger class declaration was moved to the header
because CodeAddressMap needs it.
The code for the nested class CodeEventLogger::NameBuffer was left in the cc file.

CpuProfiler now is inherit CodeEventListener but not used
the loggers infrastructure yet due to the complex initialization schema. I'd like to fix that in a separate cl.

BUG=none
TEST=current test set.
R=yangguo@chromium.org, yurys@chromium.org

Review URL: https://codereview.chromium.org/19724007

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15911 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      141ada02
  55. 23 Jul, 2013 1 commit
  57. 18 Jul, 2013 1 commit
    • yurys@chromium.org's avatar
      Fix data race in SamplingCircularQueue · 97681be4
      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
      97681be4
  59. 07 Jul, 2013 1 commit
    • loislo@chromium.org's avatar
      CPUProfiler: Improve line numbers support in profiler. · 5571dc42
      loislo@chromium.org authored 
      1) report line number even if a script has no resource_name (evals);
  a) do that for already compiled functions in log.cc;
  b) do that for fresh evals in compiler.cc;

2) Implement the test for LineNumbers and make it fast and stable, otherwise we have to wait for tick samples;
  a) move processor_->Join() call into new Processor::StopSynchronously method;
  b) Process all the CodeEvents even if we are stopping Processor thread;
  c) make getters for generator and processor;

3) Fix the test for Jit that didn't expect line numbers;

4) Minor refactoring:
  a) in ProcessTicks;
  b) rename enqueue_order_ to last_code_event_id_ for better readability;
  c) rename dequeue_order_ to last_processed_code_event_id_ and make it a member for better readability;

BUG=
TEST=test-profile-generator/LineNumber
R=jkummerow@chromium.org, yurys@chromium.org

Review URL: https://codereview.chromium.org/18058008

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