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
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
All the tests that started crashing create ProfilerEventsProcessor on the stack. After r16284 SamplingCircularQueue buffer is allocated as a field of the queue instead of separate heap object. This increased self size of ProfilerEventsProcessor by about 1Mb. Windows malloc fails to allocate such an object on the stack and crashes.
BUG=
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/23093022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16287 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
All of these values are derived from the self samples count and there is no need to evaluate them in v8 when clients can do that when needed on their side.
Also added unsigned GetHitCount() which should be used instead of double GetSelfSamplesCount(). I'm going to deprecate the latter one once Blink has switched to GetHitCount.
BUG=267595
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/22710006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16119 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The start and end time are now measured in microseconds and the type is int64_t.
This way it seems more natural as we are going to support submilisecond sampling
rate soon. Also it fixes cctest/test-cpu-profiler/ProfileStartEndTime test
failure caused by comparison between long double and double.
TEST=cctest/test-cpu-profiler/ProfileStartEndTime
BUG=v8:2824
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/22155003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16067 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The start and end time are now measured in microseconds and the type is int64_t. This way it seems more natural as we are going to support submilisecond sampling rate soon. Also it fixes cctest/test-cpu-profiler/ProfileStartEndTime test failure caused by comparison between long double and double.
TEST=cctest/test-cpu-profiler/ProfileStartEndTime
BUG=v8:2824
R=alph@chromium.org, bmeurer@chromium.org
Review URL: https://codereview.chromium.org/22172002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16049 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I'm going to change CPU profiler API and deprecate GetSelfTime, GetTotalTime and GetTotalSamplesCount on CpuProfileNode as all of those values are derived from self samples count and sampling rate. The sampling rate in turn is calculate based on the profiling duration so having start/end time and total sample count is enough for calculating smpling rate.
BUG=267595
R=alph@chromium.org, bmeurer@chromium.org
Review URL: https://codereview.chromium.org/21918002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@16039 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
The SafeStackFrameIterator used by CPU profiler checked if Isolate::c_entry_fp is null and if it is not it would think that the control flow currently is in some native code. This assumption is wrong because the native code could have called a JS function but JSEntryStub would not reset c_entry_fp to NULL in that case. This CL adds a check in SafeStackFrameIterator::IsValidTop for the case when there is a JAVA_SCRIPT frame on top of EXIT frame.
Also this CL changes ExternalCallbackScope behavior to provide access to the whole stack of the scope objects instead of only top one. This allowed to provide exact callback names for those EXIT frames where external callbacks are called. Without this change it was possible only for the top most native call.
BUG=None
R=loislo@chromium.org, yangguo@chromium.org
Review URL: https://codereview.chromium.org/19775017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15832 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
When pc is inside FunctionApply builtin function the top frame may be either
2) Internal stack frame created by FunctionApply itself.
In this case we know its caller's pc and can correctly resolve calling function.
1) Frame of the calling JavaScript function that invoked .apply(). In this case we have no practical reliable way to find out the caller's pc so we mark the caller's frame as 'unresolved'.
All this logic is implemented in ProfileGenerator. SafeStackFrameIterator is extended to provide type of the current top stack frame (iteration actually starts from the caller's frame as we know top function from pc).
BUG=252097
R=jkummerow@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/18269003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15468 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
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
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
CPU profiler doesn't use stack handlers so there is no need to iterate through them while traversing stack. This change SafeStackFrameIterator always iterate only frames and removes checks corresponding to the handlers iteration.
The problem described in the bug occurred because of a false assumption in SafeStackFrameIterator that if Isolate::c_entry_fp is not NULL then the top frame on the stack is always a C++ frame. It is false because we may have entered JS code again, in which case JS_ENTRY code stub generated by JSEntryStub::GenerateBody() will save current c_entry_fp value but not reset it to NULL and after that it will create ENTRY stack frame and JS_ENTRY handler on the stack and put the latter into Isolate::handler(top). This means that if we start iterating from c_entry_fp frame and try to compare the frame's sp with Isolate::handler()->address() it will turn out that frame->sp() > handler->address() and the condition in SafeStackFrameIterator::CanIterateHandles is not held.
BUG=252097
R=loislo@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/17589022
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15348 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change modifies code produced by BaseLoadStubCompiler::GenerateLoadCallback so that instead of calling AccessorGetter direcly it calls InvokeAccessorGetter which changes VM state and calls the actual callback. This way CPU profiler knows which external callback is being executed in this case. Indirect call happens only if CpuProfiler::is_profiling() is true.
This is exactly same change as r15116 with a build fix for test-api.cc
BUG=244580
TBR=danno@chromium.org
Review URL: https://codereview.chromium.org/16858013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15135 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This reverts commit f323d984a73bab345c4eab5c1907552ccfa7ccaa.
Broke compilation on the bots with an error that doesn't occur locally:
CXX(target) /mnt/data/b/build/slave/v8-linux-debug/build/v8/out/Debug/obj.target/cctest/test/cctest/test-bignum-dtoa.o
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = int]’:
../test/cctest/test-api.cc:1129: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = unsigned int]’:
../test/cctest/test-api.cc:1136: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = double]’:
../test/cctest/test-api.cc:1143: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = bool]’:
../test/cctest/test-api.cc:1150: error: insufficient contextual information to determine type
../test/cctest/test-api.cc: In function ‘void FastReturnValueCallback(const v8::FunctionCallbackInfo<v8::Value>&) [with T = void]’:
../test/cctest/test-api.cc:1157: error: insufficient contextual information to determine type
CXX(target) /mnt/data/b/build/slave/v8-linux-debug/build/v8/out/Debug/obj.target/cctest/test/cctest/test-circular-queue.o
BUG=None
TBR=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/16838013
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15117 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change fixes the case when the accessors are invoked from JSObject::{Get,Set}PropertyWithCallback.
It already works for inlined calls generated by StoreStubCompiler::CompileStoreCallback. The same still needs to be fixed for getter invocations generated by BaseLoadStubCompiler::CompileLoadCallback, corresponding case is commented out in the new test.
This is a slightly modified version of r14915 which was rolled back due to test timeout on Windows. Compared to r14915 the new tests use OS::TimeCurrentMillis instead of OS::Ticks as OS::Ticks has ms precision on Windows and trying to wait 10 ticks (us) will result in at least 1 ms pause.
BUG=244580
R=jkummerow@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/15995017
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14932 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change fixes the case when the accessors are invoked from JSObject::{Get,Set}PropertyWithCallback.
It already works for inlined calls generated by StoreStubCompiler::CompileStoreCallback. The same still needs to be fixed for getter invocations generated by BaseLoadStubCompiler::CompileLoadCallback, corresponding case is commented out in the new test.
BUG=244580
R=jkummerow@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/16004007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14915 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
