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
Most of these tests had some problems (failure, crash or timeout), but which problem exactly cannot be retrieved anymore.
We let them rum for a while with a broader test expectation (pass fail slow) and analyse the results.
Tests that crash get a crash expectation. Timeouts will get a timeout expectation.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/18319005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15409 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
%CompleteOptimization attempts to install optimized functions
that the parallel thread has put on the output queue, as long as
the function is marked with a builtin. However, activating the
debugger will set all functions to the lazy recompile builtin,
without the function being on the parallel recompilation pipeline.
So we wait for the function to finish parallel recompilation
while it's marked by a builtin that's unrelated to parallel
recompilation.
R=hpayer@chromium.org
BUG=
Review URL: https://codereview.chromium.org/18129003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15404 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r15384 (d553efd)
Original commit message:
Adds more coverage for function entry hook, sufficient to capture profiles
that are contiguous from C++, through JS and back out to C++.
BUG=
Review URL: https://codereview.chromium.org/18184011
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15396 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r15383 (3e90aaf)
Original commit message:
* Cleanup of LCallNewArray::PrintDataTo() method
* Created HCallNewArray::PrintDataTo()
* Created many more tests in array-constructor-feedback.js
* Removed redundant instructions in
GenerateRecordCallTarget
* Bugfix in CreateArrayDispatchOneArgument: on a call to
new Array(0), we'd like to set the type feedback cell to
a packed elements kind, but we shouldn't do it if the
cell contains the megamorphic sentinel.
* When used from crankshaft, ArrayConstructorStubs can
avoid verifying that the function being called is the
array function from the current native context, relying
instead on the fact that crankshaft issues an
HCheckFunction to protect the constructor call. (this
new minor key is used in LCodeGen::DoCallNewArray(), and
influences code generation in
CodeStubGraphBuilderBase::BuildArrayConstructor()).
* Optimization: the array constructor specialized for
FAST_SMI_ELEMENTS can save some instructions by looking
up the correct map on the passed in constructor, rather
than indexing into the array of cached maps per element
kind.
BUG=
Review URL: https://codereview.chromium.org/18191007
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15395 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
r1656 contains a bug fix for the make generator to correctly regenerate
Makefiles if a gyp was touched. Before, it would assume that it is
running in the top-level directory. However, the v8 standalone build
puts the generated Makefile into the out subdirectory, and so gyp
failed to locate the gyp binary.
BUG=none
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/18053015
Patch from Jochen Eisinger <jochen@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15388 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
