This switches full-codegen to no longer push and pop StackHandler
markers onto the operand stack, but relies on a range-based handler
table instead. We only use StackHandlers in JSEntryStubs to mark the
transition from C to JS code.
Note that this makes deoptimization and OSR from within any try-block
work out of the box, makes the non-exception paths faster and should
overall be neutral on the memory footprint (pros).
On the other hand it makes the exception paths slower and actually
throwing and exception more expensive (cons).
R=yangguo@chromium.org
TEST=cctest/test-run-jsexceptions/DeoptTry
Review URL: https://codereview.chromium.org/1010883002
Cr-Commit-Position: refs/heads/master@{#27440}
This relands commit 96f79568a9.
This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.
There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.
With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/997213003
Cr-Commit-Position: refs/heads/master@{#27263}
Reason for revert:
Layout test failure in inspector/sources/debugger/debugger-pause-on-promise-rejection.html
Original issue's description:
> Remove kind field from StackHandler.
>
> This makes the Isolate::Throw logic not depend on a prediction of
> whether an exception is caught or uncaught. Such a prediction is
> inherently undecidable because a finally block can decide between
> consuming or re-throwing an exception depending on arbitray control
> flow.
>
> There still is a conservative prediction mechanism in place that
> components like the debugger or tracing can use for reporting.
>
> With this change we can get rid of the StackHandler::kind field, a
> pre-requisite to do table-based lookups of exception handlers.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/96f79568a926966ebcf0685bf9adc947f4e1fbff
> Cr-Commit-Position: refs/heads/master@{#27210}
TBR=yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1009903002
Cr-Commit-Position: refs/heads/master@{#27215}
This makes the Isolate::Throw logic not depend on a prediction of
whether an exception is caught or uncaught. Such a prediction is
inherently undecidable because a finally block can decide between
consuming or re-throwing an exception depending on arbitray control
flow.
There still is a conservative prediction mechanism in place that
components like the debugger or tracing can use for reporting.
With this change we can get rid of the StackHandler::kind field, a
pre-requisite to do table-based lookups of exception handlers.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1002203002
Cr-Commit-Position: refs/heads/master@{#27210}
This reduces the size of the StackHandler by yet another word. We no
longer need to keep track of the frame pointer, as the stack walk will
be able to recalculate it.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/991893003
Cr-Commit-Position: refs/heads/master@{#27115}
This reduces the size of the StackHandler by one word. We no longer
need to keep track of the code object, as the stack walk finds it.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/985803002
Cr-Commit-Position: refs/heads/master@{#27103}
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
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
In order to fix https://code.google.com/p/chromium/issues/detail?id=252097 I
need to change SafeStackTraceFrameIterator. Stack iterators hierarchy looks
excessively complicated and I'd like to flatten it a bit by removing some
intermediate classes. In particular there are two hierarchies sharing
JavaScriptFrameIteratorTemp<T> template for no good reason.
This change extracts some of JavaScriptFrameIteratorTemp functionality directly
into SafeStackTraceFrameIterator. This made it obvious that a few checks were
performed twice.
The rest of JavaScriptFrameIteratorTemp<T> is merged with
JavaScriptFrameIterator. Now that the class is not a template some of its
implementation is moved from frames-inl.h into frames.cc
So in this change I removed JavaScriptFrameIterator and
SafeJavaScriptFrameIterator. As the next step I'm going to merge
SafeStackFrameIterator into SafeStackTraceFrameIterator.
BUG=None
R=loislo@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/16917004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15275 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL extends the generator suspend and resume implementation to
capture values on the operand stack.
It factors out some helpers to measure and access the operand stack into
the JavaScriptFrame class. It also refactors the suspend and resume
helpers to avoid handle allocation.
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14348003
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14458 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Original commit message:
Add a level of indirection to exception handler addresses.
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets. The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.
R=vegorov@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8538011
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9977 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
To support deoptimization of exception handlers, the handler address in the
stack is converted to a pair of code object and an index into a separate
table of code offsets. The index part is invariant under deoptimization.
The index is packed into the handler state field so that handler size does
not change.
R=vegorov@chromium.org,fschneider@chromium.org
BUG=
TEST=
Review URL: http://codereview.chromium.org/8462010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9975 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Remove the try/finally used for with and catch. Instead of using
try/finally to handle break and continue from with or catch,
statically track nesting dept and clean up when compiling break or
continue.
And instead of using try/finally to handle throw to handler in a frame
whose pc is inside a with or catch, store the context that the handler
should run in in the handler itself.
BUG=
TEST=
Review URL: http://codereview.chromium.org/7618007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8922 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Change caller_sp() to always point to the place after outgoing arguments.
Change deoptimizer to use absolute stack slot addresses for deferred HeapNumber's materialization.
(This is reapplication of r7504 with fix for mozilla testsuite failures).
Review URL: http://codereview.chromium.org/6677164
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7516 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
