This introduces a bailout point for class literals right after the
%DefineClass function has been called. Otherwise the FrameState after
class literal evaluation might contain the literal itself.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-480819
BUG=chromium:480819
LOG=N
Review URL: https://codereview.chromium.org/1104673004
Cr-Commit-Position: refs/heads/master@{#28043}
This is a workaround to make the debugger happy about TurboFan frames
when the debugger causes frame inspection. Note that this can happen
because the debugger can be activated while there still are optimized
TurboFan activations on the stack.
R=ishell@chromium.org
BUG=chromium:465298
TEST=mjsunit/regress/regress-crbug-465298
LOG=N
Review URL: https://codereview.chromium.org/1074793003
Cr-Commit-Position: refs/heads/master@{#27717}
The motivation is that we prefer to avoid creating internal properties, and we have a usable field on maps ("transitions", which is not used for prototype maps).
This CL also ensures the invariant that prototype maps are never shared, even if they are in dictionary mode.
Review URL: https://codereview.chromium.org/1033653002
Cr-Commit-Position: refs/heads/master@{#27617}
Optimistically pushing a lot of arguments can run into the stack limit of the process, at least on operating systems where this limit is close to the limit that V8 sets for itself.
BUG=chromium:469768
LOG=y
Review URL: https://codereview.chromium.org/1056913003
Cr-Commit-Position: refs/heads/master@{#27614}
A bug allows JSObject literals with elements to have the elements in the
boilerplate modified.
BUG=466993
LOG=N
Review URL: https://codereview.chromium.org/1037273002
Cr-Commit-Position: refs/heads/master@{#27511}
Also fix Debug.showBreakPoints for multiple break points at the same location.
BUG=v8:3960
LOG=N
Review URL: https://codereview.chromium.org/998253005
Cr-Commit-Position: refs/heads/master@{#27444}
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}
The test demonstrates a bad interaction between arguments object
materialization, escape analysis and exception handling.
We can return a wrong arguments object if we materialize arguments
object (using f.arguments) and then throw around f's frame so that f
does not clean up the materialized frame information (see the
MaterializedObjectStore in deoptimizer.h/.cc). If we enter another
function that has the same frame pointer and request an arguments object
of (or lazily deoptimize) that function, we can get the materialized
object of the original function.
We should clean up the materialized object store when we unwind the
stack.
BUG=v8:3985
LOG=n
Review URL: https://codereview.chromium.org/1032623003
Cr-Commit-Position: refs/heads/master@{#27406}
The problem manifests itself when parsing manages to return something
meaningful in the presence of a stack overflow. This happens because
calling ParserBase::Next() will still return one valid token on stack
overflow, before starting to return invalid tokens.
Take the following input as example:
a.map(v => v + 1);
| |
already next token
parsed (which will be an invalid token
(identifier) because of a stack overflow)
The "v" may have been already parsed into a VariableProxy, then if a
stack overflow occurs, next token will be an invalid token (instead
of Token::ARROW), but the parser will return the VariableProxy.
This always happens when lazy-parsing arrow functions, so the position
in the input stream where the the arrow function code ends is known.
This fix adds a check that ensures that parsing ended at the end
position of the arrow function.
BUG=465671
LOG=N
Review URL: https://codereview.chromium.org/1023483003
Cr-Commit-Position: refs/heads/master@{#27325}
This ensures that there is only one stub that deals with unwinding the
stack. Having more than one place containing that logic is brittle and
error prone, especially when it is a corner case only for RangeErrors.
R=titzer@chromium.org
TEST=mjsunit/regress/regress-crbug-467047
BUG=chromium:467047
LOG=N
Review URL: https://codereview.chromium.org/1012103002
Cr-Commit-Position: refs/heads/master@{#27243}
The evaluation order of receiver versus arguments is not properly
defined by C++. This caused issues with Clang where the environment
changed after the receiveing environment was already loaded.
R=jarin@chromium.org
BUG=chromium:467531
TEST=mjsunit/regress/regress-crbug-467531
LOG=N
Review URL: https://codereview.chromium.org/1015683002
Cr-Commit-Position: refs/heads/master@{#27238}
ES6 specs the function length property (it was not part of ES5) and
it makes it configurable.
BUG=v8:3045
LOG=N
R=mstarzinger@chromium.org, adamk@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/993073002
Cr-Commit-Position: refs/heads/master@{#27190}
This involved renaming apart a few more intrinsics. In the long run,
we want to clean up redundant intrinsics which just delegate.
BUG=v8:3947
LOG=n
Review URL: https://codereview.chromium.org/984963002
Cr-Commit-Position: refs/heads/master@{#27043}
