1. 11 Sep, 2013 1 commit
  2. 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
  3. 05 Sep, 2013 5 commits
  4. 04 Sep, 2013 1 commit
  5. 29 Aug, 2013 3 commits
  6. 28 Aug, 2013 6 commits
  7. 26 Aug, 2013 2 commits
    • yurys@chromium.org's avatar
      Use signals for cpu profiling on Mac OS X · a29ceb7b
      yurys@chromium.org authored
      A while ago in r2315 Mac OS X cpu profiler implementation was changed to pause sampled thread instead of sending SIGPROF signal. That was done because at that point profiler send the signal to the whole process and it was handled on a random thread. Now that signal-based implementation uses pthread_kill it may well be used on Mac OS X too.
      
      BUG=v8:2814
      R=bmeurer@chromium.org, svenpanne@chromium.org
      
      Review URL: https://codereview.chromium.org/23115005
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16320 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      a29ceb7b
    • 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
  8. 23 Aug, 2013 1 commit
  9. 07 Aug, 2013 1 commit
  10. 30 Jul, 2013 1 commit
    • yurys@chromium.org's avatar
      Simplify sampling rate calculation · 6ba502fa
      yurys@chromium.org authored
      Sampling rate is now calculated as total number of samples divided by profiling time in ms. Before the patch the sampling rate was updated once per 100ms which doesn't have any obvious advantage over the simpler method.
      
      Also we are going to get rid of the profile node self and total time calculation in the v8 CPU profiler and only expose profiling start/end time for CpuProfile and number of ticks on each ProfileNode and let clients do all the math should they need it.
      
      BUG=None
      R=bmeurer@chromium.org, loislo@chromium.org
      
      Review URL: https://codereview.chromium.org/21105003
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      6ba502fa
  11. 23 Jul, 2013 1 commit
  12. 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
  13. 06 Jul, 2013 1 commit
  14. 05 Jul, 2013 1 commit
  15. 02 Jul, 2013 4 commits
  16. 01 Jul, 2013 9 commits
  17. 20 Jun, 2013 1 commit