Do not allow invocation of ArrayBuffer and array buffer views' constructors as functions.

ES6 bug 695 (https://bugs.ecmascript.org/show_bug.cgi?id=695).
This never worked in WebKit, so no compatibility issues.

R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/17904007

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@15346 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix elements-kind test to disable optimization of important functions under test; add simpler versions of elements kind test.

Review URL: https://codereview.chromium.org/17872002

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@15347 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Do not iterate stack handlers in SafeStackFrameIterator

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: https://v8.googlecode.com/svn/branches/bleeding_edge@15348 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Extract StackFrameIteratorBase

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: https://v8.googlecode.com/svn/branches/bleeding_edge@15349 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Add myself to OWNERS.

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@15350 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Fix the compilation of gdbjit

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/18023005

Patch from Haitao Feng <haitao.feng@intel.com>.

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@15351 ce2b1a6d-e550-0410-aec6-3dcde31c8c00