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
* 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=
R=danno@chromium.org
Review URL: https://codereview.chromium.org/17091002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15383 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r15358 (3af77be)
Original commit message:
The check for internalized strings relied on the fact that we had less
than 64 distinct InstanceTypes. We are hitting that boundary, so this
check needs to be more comprehensive. In fact, two bits need to be
tested: verify that kNotStringTag isn't set, and that kInternalizedTag
is set.
BUG=
Review URL: https://codereview.chromium.org/18083004
Patch from Balazs Kilvady <kilvadyb@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15368 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This change introduces StackFrameIteratorBase which owns singleton frame instances and encapsulates some basic iterator functionality. It has two actual implementations: StackFrameIterator and SafeStackFrameIterator.
All logic specific to frame iteration at a random point (basically checks that fp and sp extracted from stack frames are within current stack boundaries) used only by CPU profiler is now concentrated in SafeStackFrameIterator.
Generic stack iteration used in all other places is put into StackFrameIterator. Also this iterator unlike SafeStackFrameIterator iterates through stack handlers.
StackAddressValidator and ExitFrameValidator classes were removed in favor of inline checks and simple methods.
BUG=None
R=loislo@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/17819003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15349 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
