it is the last patch of https://codereview.chromium.org/1012633002
All that we need here is to push the collected info to the profiler
and convert it into actionable information about deopt.
On the Next: get the info accessible by embedder.
BUG=chromium:452067
LOG=n
TEST=DeoptAtFirstLevelInlinedSource, DeoptAtSecondLevelInlinedSource, DeoptUntrackedFunction
Review URL: https://codereview.chromium.org/1013143003
Cr-Commit-Position: refs/heads/master@{#27403}
We use slightly different schema for JumpTable on arm64 than for x64.
We do a branch (B) to the JumpTable from the code,
then a branch (B) to the end of jump table code
and then branch to the deoptimizer code with putting
the return address into lr register (Call which is actually Blr).
As a result the 'from' address in Deoptimizer always points to
the end of JumpTable code and we can get nothing from this information.
0) I moved save_doubles and needs_frame code out of for_loop.
1) I replaced B commands with Bl so we put different return addresses
to lr register for the different jump table entries and replaced
the final Call with Br which do not touch lr register.
Also I removed the last_entry check so we will always do the Bl
even for the last entry because we need the right address in lr.
I don't think that this will affect the performance because it
just one more branch for entire deopt mechanics.
BUG=chromium:452067
LOG=n
Review URL: https://codereview.chromium.org/984893003
Cr-Commit-Position: refs/heads/master@{#27094}
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}
Reason for revert:
Some tests still flaky
Original issue's description:
> CpuProfiler: enable tests except four failing tests.
>
> Four tests are failing due to a problem with no frame ranges.
>
> BUG=
> LOG=n
>
> Committed: https://crrev.com/2be160e726f2be6272b77e53fbd556aded6024f1
> Cr-Commit-Position: refs/heads/master@{#27035}
TBR=yurys@chromium.org,svenpanne@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/987553005
Cr-Commit-Position: refs/heads/master@{#27037}
Four tests are failing due to a problem with no frame ranges.
BUG=
LOG=n
Review URL: https://codereview.chromium.org/976203003
Cr-Commit-Position: refs/heads/master@{#27035}
The root of problem is the fact that we don't track the position of 'this' statement but use them when visit compare statement.
As a result we have -1 as the position of left expression and the resulting relative position is negative and doesn't fit into BitField.
BUG=452067
TEST=test-cpu-profiler/SourceLocation
LOG=n
Review URL: https://codereview.chromium.org/940593002
Cr-Commit-Position: refs/heads/master@{#26741}
1) create beefy RelocInfo table when cpu profiler is active, so if a function
was optimized when profiler was active RelocInfo would get separate DeoptInfo
for the each deopt case.
2) push DeoptInfo from CodeEntry to ProfileNode.
When deopt happens we put the info collected on #1 into CodeEntry and record stack sample.
On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list.
Sample profile dump.
[Top down]:
0 (root) 0 #1
1 29 #2
1 test 29 #3
2 opt_function 29 #4
2 opt_function 29 #5
deopted at 118 with reason 'not a heap number'
deopted at 137 with reason 'division by zero'
BUG=452067
LOG=n
Committed: https://crrev.com/ce8701b247d3c6604f24f17a90c02d17b4417f54
Cr-Commit-Position: refs/heads/master@{#26615}
Review URL: https://codereview.chromium.org/919953002
Cr-Commit-Position: refs/heads/master@{#26630}
Reason for revert:
static initializers broke the build
Original issue's description:
> CPUProfiler: Push deopt reason further to ProfileNode.
>
> 1) create beefy RelocInfo table when cpu profiler is active, so if a function
> was optimized when profiler was active RelocInfo would get separate DeoptInfo
> for the each deopt case.
>
> 2) push DeoptInfo from CodeEntry to ProfileNode.
> When deopt happens we put the info collected on #1 into CodeEntry and record stack sample.
> On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list.
>
> Sample profile dump.
> [Top down]:
> 0 (root) 0 #1
> 1 29 #2
> 5 test 29 #3
> 3 opt_function 29 #4
> deopted at 52 with reason 'not a heap number'
> deopted at 71 with reason 'division by zero'
>
> BUG=452067
> LOG=n
>
> Committed: https://crrev.com/ce8701b247d3c6604f24f17a90c02d17b4417f54
> Cr-Commit-Position: refs/heads/master@{#26615}
TBR=jarin@chromium.org,svenpanne@chromium.org,yurys@chromium.org,alph@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=452067
Review URL: https://codereview.chromium.org/915173005
Cr-Commit-Position: refs/heads/master@{#26616}
1) create beefy RelocInfo table when cpu profiler is active, so if a function
was optimized when profiler was active RelocInfo would get separate DeoptInfo
for the each deopt case.
2) push DeoptInfo from CodeEntry to ProfileNode.
When deopt happens we put the info collected on #1 into CodeEntry and record stack sample.
On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list.
Sample profile dump.
[Top down]:
0 (root) 0 #1
1 29 #2
5 test 29 #3
3 opt_function 29 #4
deopted at 52 with reason 'not a heap number'
deopted at 71 with reason 'division by zero'
BUG=452067
LOG=n
Review URL: https://codereview.chromium.org/919953002
Cr-Commit-Position: refs/heads/master@{#26615}
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}
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.
This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.
3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
Patch from Denis Pravdin <denis.pravdin@intel.com>;
R=svenpanne@chromium.org, yurys@chromium.org
Review URL: https://codereview.chromium.org/682143003
Patch from Weiliang <weiliang.lin@intel.com>.
Cr-Commit-Position: refs/heads/master@{#25182}
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25182 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Reason for revert:
It broke layout test fast/events/window-onerror-02.html, error column reported by window.onerror is now wrong (I believe it is because of the change in full-codegen):
http://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/652
Original issue's description:
> Extend CPU profiler with mapping ticks to source lines
>
> The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
> During generation code and relocation info are generated simultaneously.
> When code generation is done you each code object has associated "relocation info".
> Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
> correspondences between the machine program counter and source locations for stack walking.
>
> This patch:
> 1. Add more source positions info in reloc info to make it suitable for source level mapping.
> The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
> (2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
> I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
>
> 2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
> If a source line is found that hit counter is increased by one for this line.
>
> 3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
> Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
>
> 4.Add a test that checks how the samples are distributed through source lines.
> It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
>
> Patch from Denis Pravdin <denis.pravdin@intel.com>
> BUG=None
> LOG=Y
> R=svenpanne@chromium.org
>
> Committed: https://code.google.com/p/v8/source/detail?r=24389TBR=svenpanne@chromium.org,danno@chromium.org,alph@chromium.org,denis.pravdin@intel.com,weiliang.lin@intel.com
BUG=None
LOG=N
Review URL: https://codereview.chromium.org/624443005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24394 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The idea behind of this solution is to use the existing "relocation info" instead of consumption the CodeLinePosition events emitted by the V8 compilers.
During generation code and relocation info are generated simultaneously.
When code generation is done you each code object has associated "relocation info".
Relocation information lets V8 to mark interesting places in the generated code: the pointers that might need to be relocated (after garbage collection),
correspondences between the machine program counter and source locations for stack walking.
This patch:
1. Add more source positions info in reloc info to make it suitable for source level mapping.
The amount of data should not be increased dramatically because (1) V8 already marks interesting places in the generated code and
(2) V8 does not write redundant information (it writes a pair (pc_offset, pos) only if pos is changed and skips other).
I measured it on Octane benchmark - for unoptimized code the number of source positions may achieve 2x ('lin_solve' from NavierStokes benchmark).
2. When a sample happens, CPU profiler finds a code object by pc, then use its reloc info to match the sample to a source line.
If a source line is found that hit counter is increased by one for this line.
3. Add a new public V8 API to get the hit source lines by CDT CPU profiler.
Note that it's expected a minor patch in Blink to pack the source level info in JSON to be shown.
4.Add a test that checks how the samples are distributed through source lines.
It tests two cases: (1) relocation info created during code generation and (2) relocation info associated with precompiled function's version.
Patch from Denis Pravdin <denis.pravdin@intel.com>
BUG=None
LOG=Y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/616963005
Patch from Denis Pravdin <denis.pravdin@intel.com>.
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24389 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The reuse of CodeCreateEvent for deopt events caused a CodeCreateEvent
fired twice for a code object. When the event was processed for the first
time it seized the no-fp-ranges from code object, so the second event
had no ranges info leaving code entry without them.
As a result when a cpu profile sample falls into the region it missed the
2nd stack frame.
LOG=N
BUG=
R=bmeurer@chromium.org, loislo@chromium.org
Review URL: https://codereview.chromium.org/290093005
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21418 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Distinguish between context bound scripts (Script) and context unbound scripts
(UnboundScript).
- Add ScriptCompiler (which will later contain functions for async compilation).
This is a breaking change, in particular, Script::New no longer exists (it is
replaced by ScriptCompiler::CompileUnbound). Script::Compile remains as a
backwards-compatible shorthand for ScriptCompiler::Compile.
Passing CompilerOptions with produce_data_to_cache = true doesn't do anything
yet; the only way to generate the data to cache is the old preparsing API. (To
be fixed in the next version.)
This is a fixed version of https://codereview.chromium.org/186723005/
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/199063003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19925 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Distinguish between context bound scripts (Script) and context unbound scripts
(UnboundScript).
- Add ScriptCompiler (which will later contain functions for async compilation).
This is a breaking change, in particular, Script::New no longer exists (it is
replaced by ScriptCompiler::CompileUnbound). Script::Compile remains as a
backwards-compatible shorthand for ScriptCompiler::Compile.
Passing CompilerOptions with produce_data_to_cache = true doesn't do anything
yet; the only way to generate the data to cache is the old preparsing API. (To
be fixed in the next version.)
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/186723005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19881 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
All methods for accessing collected profiles by index are deprecated. The indexed storage may well be implemented by the embedder should he need it. CpuProfiler's responsibility is just to create CpuProfile object that contains all collected data and whose lifetime can be managed by the embedder.
BUG=chromium:327298
LOG=Y
R=svenpanne@chromium.org
Review URL: https://codereview.chromium.org/117353002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18337 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Made operator* return reference to the raw type, not pointer. New method 'get()' should be used when raw pointer is needed.
Also removed useless inline modifier from the SmaprtPointer methods and added const modifier to the methods that don't change smart pointer.
Made ~SmartPointerBase protected to avoid accidental calls of the non-virtual base class's destructor.
drive-by: fixed use after free in src/factory.cc
BUG=None
LOG=N
R=alph@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/101763003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18275 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Profiler is now started from JavaScript. Since we always capture stack trace when starting profiler there should always be at least one expected sample in the profile.
Also changed ProfilerEventsProcessor::AddCurrentStack to make sure it call TickSample::Init to instead of custom initialization code.
BUG=v8:2920
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/25686011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17140 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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
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
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
