- 11 Sep, 2013 1 commit
-
-
dcarney@chromium.org authored
R=svenpanne@chromium.org BUG= Review URL: https://codereview.chromium.org/23468021 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16631 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 Sep, 2013 1 commit
-
-
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
-
- 05 Sep, 2013 5 commits
-
-
loislo@chromium.org authored
Current v8 implementation may disable optimization for a particular function or block it with help of dont_optimize flag. The patch propagates the reason of that to the SharedFunctionInfo where cpu profiler can get it. SharedFunctionInfo is a heap object so I extracted 8 bits from OptsCount for handling bailout reason code. BUG=none TEST=test-profile-generator/BailoutReason R=yangguo@chromium.org Review URL: https://codereview.chromium.org/23817003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16555 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
The change made cctest/test-cpu-profiler/CollectCpuProfile and cctest/test-cpu-profiler/JsNative1JsNative2JsSample flaky. BUG=v8:2871 TBR=bmeurer@chromium.org Review URL: https://codereview.chromium.org/23615011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16553 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
dcarney@chromium.org authored
TBR=bmeurer@chromium.org,yurys@chromium.org BUG= Review URL: https://codereview.chromium.org/23452023 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16550 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
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
-
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. BUG=v8:2814 R=bmeurer@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/23583036 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16548 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Sep, 2013 1 commit
-
-
yurys@chromium.org authored
The only way to change it at the moment is using a command line flag. We are going to add a setting to Chrome DevTools which would allow chaning default interval and that requires proper v8 API. BUG=v8:2814 R=bmeurer@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/23902004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16525 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Aug, 2013 3 commits
-
-
yurys@chromium.org authored
Now that CpuProfiler sends does sampling on the profile event processing thread there is no need to launch sampler thread. The latter is used only for --prof profiler. BUG=v8:2814 R=bmeurer@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/23011029 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16430 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
This change removes --prof-lazy command line flag that was introduced for the old CPU profiler implementation in Chrome DevTools. DevTools now use profiler API defined in v8-profiler.h This change also removes methods for pausing resuming --prof profiler. These methods were deprecated in v.3.20 (https://code.google.com/p/v8/source/browse/branches/3.20/include/v8.h#4629) After this change the profiler will always start if --prof option is passed and can be stopped either in the tests or if write to log file fails. BUG=None R=bmeurer@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/23478010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16417 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(), which are broken in several ways. The ElapsedTimer class implements a stopwatch using TimeTicks::HighResNow() for high resolution, monotonic timing. Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime() methods to actually return the time relative to the unix epoch as stated in the documentation (previously that was relative to some arbitrary point in time, i.e. boot time). The previous Windows issues have been resolved, and we now use GetTickCount64() on Windows Vista and later, falling back to timeGetTime() with rollover protection for earlier Windows versions. BUG=v8:2853 R=machenbach@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/23490015 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16413 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Aug, 2013 6 commits
-
-
bmeurer@chromium.org authored
Revert "Cross-compiling from Linux to Android requires -lrt for the host toolset.", "Fix Visual Studio debug build after r16398." and "Reland "Add Chromium-style TimeDelta, Time and TimeTicks classes, and a new ElapsedTimer class."" This reverts commit r16398, r16399 and r16402 for breaking the Windows WebKit tests. Will reland fix which doesn't use High Resolution Timer for ElapsedTimer (we suspect QueryPerformanceCounter overhead is responsible for test breakage). TBR=machenbach@chromium.org Review URL: https://codereview.chromium.org/23710002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16405 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(), which are broken in several ways. The ElapsedTimer class implements a stopwatch using TimeTicks::HighResNow() for high resolution, monotonic timing. Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime() methods to actually return the time relative to the unix epoch as stated in the documentation (previously that was relative to some arbitrary point in time, i.e. boot time). BUG=v8:2853 R=machenbach@chromium.org Review URL: https://codereview.chromium.org/23469013 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
This reverts commit r16390 for breaking the Windows build. Will reland fixed version, which also uses the platform/ folder instead of time/ folder as per offline discussion. TBR=machenbach@chromium.org Review URL: https://codereview.chromium.org/23690003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16391 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(), which are broken in several ways. The ElapsedTimer class implements a stopwatch using TimeTicks::HighResNow() for high resolution, monotonic timing. Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime() methods to actually return the time relative to the unix epoch as stated in the documentation (previously that was relative to some arbitrary point in time, i.e. boot time). BUG=v8:2853 R=machenbach@chromium.org, yurys@chromium.org Committed: https://code.google.com/p/v8/source/detail?r=16388 Review URL: https://codereview.chromium.org/23295034 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16390 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
This reverts commit r16388 for breaking build due to merge typo, will reland with typo fixed. TBR=machenbach@chromium.org Review URL: https://codereview.chromium.org/23698002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
These classes are meant to replace OS::Ticks() and OS::TimeCurrentMillis(), which are broken in several ways. The ElapsedTimer class implements a stopwatch using TimeTicks::HighResNow() for high resolution, monotonic timing. Also fix the CpuProfile::GetStartTime() and CpuProfile::GetEndTime() methods to actually return the time relative to the unix epoch as stated in the documentation (previously that was relative to some arbitrary point in time, i.e. boot time). BUG=v8:2853 R=machenbach@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/23295034 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16388 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 Aug, 2013 2 commits
-
-
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
-
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
-
- 23 Aug, 2013 1 commit
-
-
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
-
- 07 Aug, 2013 1 commit
-
-
yurys@chromium.org authored
This change provides an API for the embedder to tell CPU profiler if it is idle or busy with some task. This way we can discriminate between idle time and some native code execution. BUG=268947 R=alph@chromium.org, yangguo@chromium.org Review URL: https://codereview.chromium.org/22412003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16109 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jul, 2013 1 commit
-
-
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
-
- 23 Jul, 2013 1 commit
-
-
loislo@chromium.org authored
CpuProfiler has almost the same api for CodeCreate* events but it was calling separately. BUG=260203 R=svenpanne@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/19916002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15817 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Jul, 2013 1 commit
-
-
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
-
- 06 Jul, 2013 1 commit
-
-
yurys@chromium.org authored
The methods that allow to filter CPU profile by security token were introduced to support console.profiles in WebKit. Now that console.profiles is removed and corresponding V8 API methods have been deprecated in 3.19 branch(https://code.google.com/p/v8/source/browse/branches/3.19/include/v8-profiler.h) it is safe to remove all that code. BUG=None R=jkummerow@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/18709003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15528 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Jul, 2013 1 commit
-
-
yangguo@chromium.org authored
R=yangguo@chromium.org Review URL: https://codereview.chromium.org/18509003 Patch from Haitao Feng <haitao.feng@intel.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15510 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Jul, 2013 4 commits
-
-
yurys@chromium.org authored
Fixed a couple of places where stored pointer to the isolate can be used instead of reading from thread local storage. BUG=None R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18418003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15457 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
When current function is FunctionCall builtin we have no reliable way to determine its caller function (in many cases the top of the sampled stack contains address of the caller but sometimes it does not). Instead of dropping the sample or its two top frames we simply mark the caller frame as '(unresolved function)'. It seems like a better approach that dropping whole sample as knowing the top function and the rest of the stack the user should be able to figure out what the caller was. This change adds builtin id to CodeEntry objects. It will be used later to add similar top frame analysis for FunctionApply and probably other builtins. BUG=None TBR=loislo@chromium.org Review URL: https://codereview.chromium.org/18422003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15436 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
This reverts commit r15426. The new test fails in Debug mode. BUG=None TBR=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18478002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15434 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
loislo@chromium.org authored
Each CpuProfileNode has resource_name string property. It cost us N * strlen(resource_name) where N is number of functions in the collected profile. We could transfer script_id instead of resource_name so it would reduce transfer size and help us to solve the problem with evals and sourceURL. BUG=none TEST=test-cpu-profiler/CollectCpuProfile R=jkummerow@chromium.org, yurys@chromium.org Committed: https://code.google.com/p/v8/source/detail?r=15429 Review URL: https://codereview.chromium.org/17642009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15433 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Jul, 2013 9 commits
-
-
loislo@chromium.org authored
This reverts commit d575f6bc8b262dac08f02913ae6e7c504c9dd900. Check is failing on debug bots. TBR= yurys@chromium.org Review URL: https://chromiumcodereview.appspot.com/18332010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
loislo@chromium.org authored
Each CpuProfileNode has resource_name string property. It cost us N * strlen(resource_name) where N is number of functions in the collected profile. We could transfer script_id instead of resource_name so it would reduce transfer size and help us to solve the problem with evals and sourceURL. BUG=none TEST=test-cpu-profiler/CollectCpuProfile R=jkummerow@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/17642009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15429 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
When current function is FunctionCall builtin we have no reliable way to determine its caller function (in many cases the top of the sampled stack contains address of the caller but sometimes it does not). Instead of dropping the sample or its two top frames we simply mark the caller frame as '(unresolved function)'. It seems like a better approach that dropping whole sample as knowing the top function and the rest of the stack the user should be able to figure out what the caller was. This change adds builtin id to CodeEntry objects. It will be used later to add similar top frame analysis for FunctionApply and probably other builtins. BUG=None R=jkummerow@chromium.org, loislo@chromium.org Review URL: https://codereview.chromium.org/18316004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15426 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yurys@chromium.org authored
The only way to get v8::CpuProfiler instance in the V8 public API is to call v8::Iolate::GetCpuProfiler(). The method will return NULL if the isolate has not been initialized yet or has been torn down already. It is the client's reponsibility to make sure that CPU profiling has been stopped before disposing of the isolate. This CL adds a test for this and several ASSRTS enforcing that assumptions. This allowed to be sure that heap is always setup when CPU profiling is being started. Based on that the number of places where already compiled functions are reported to the profiler event processor boils down to the single place (CpuProfiler::StartProcessorIfNotStarted). I'm going to rely on this assumption in further changes. BUG=None R=loislo@chromium.org, yangguo@chromium.org Review URL: https://codereview.chromium.org/18336002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15415 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
Following up on https://codereview.chromium.org/18353002, there's no need to pass the profiles to ProfilerEventsProcessor's constructor. BUG= R=danno@chromium.org Review URL: https://codereview.chromium.org/18332004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15413 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
bmeurer@chromium.org authored
BUG= R=jkummerow@chromium.org Review URL: https://codereview.chromium.org/18353002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15412 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
loislo@chromium.org authored
The bodies of methods in ProfilerEventProcessor were moved into CpuProfiler. Multiple NewCodeEntry methods in CpuProfilesCollection were replaced with one which simply passes arguments to the CodeEntry constructor. And CpuProfiler just calls this method when it needs a CodeEntry object. This NewCodeEntry method is required because CpuProfilesCollection keeps ownership of CodeEntry objects. BUG=255392 TEST=existing tests R=yangguo@chromium.org, yurys@chromium.org Committed: https://code.google.com/p/v8/source/detail?r=15405 Review URL: https://codereview.chromium.org/18053004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15407 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
loislo@chromium.org authored
This reverts commit 76adf84b83ec3c0b261cbc29369ce4ac83f9d002. windows compilation failed BUG=none TBR=yurys@chromium.org Review URL: https://codereview.chromium.org/18344002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15406 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
loislo@chromium.org authored
The bodies of methods in ProfilerEventProcessor were moved into CpuProfiler. Multiple NewCodeEntry methods in CpuProfilesCollection were replaced with one which simply passes arguments to the CodeEntry constructor. And CpuProfiler just calls this method when it needs a CodeEntry object. This NewCodeEntry method is required because CpuProfilesCollection keeps ownership of CodeEntry objects. BUG=255392 TEST=existing tests R=yangguo@chromium.org, yurys@chromium.org Review URL: https://codereview.chromium.org/18053004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15405 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Jun, 2013 1 commit
-
-
yurys@chromium.org authored
This change modifies memory accesses to ensure proper load/store ordering. BUG=249750 R=dvyukov@google.com, jkummerow@chromium.org Review URL: https://codereview.chromium.org/17294004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15219 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-