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}
Function name property is now standardized in ES6. It was a Mozilla proprietary
extension before. With ES6, the property was made configurable, so that it can
be used instead of another proprietary property, displayName.
This is a revert of revert c791d84112.
Last time this broke a Chrome browser test which has since been updated:
5f75a3be4c
BUG=v8:3333
LOG=N
R=mstarzinger@chromium.org,verwaest@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/977003004
Cr-Commit-Position: refs/heads/master@{#26996}
This is partially based on r21609 but that CL was incomplete.
Function name is still non writable so one has to use defineProperty
to change the actual value.
BUG=v8:3333
LOG=N
R=adamk, mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/960343002
Cr-Commit-Position: refs/heads/master@{#26924}
It must always populate int32_value_, even if that's lossy, because other code (specifically, constant folding for truncating operations) relies on it.
BUG=v8:3865
LOG=y
Review URL: https://codereview.chromium.org/897263002
Cr-Commit-Position: refs/heads/master@{#26453}
Both SameValue and SameValueZero consider different NaNs equal, so we
better assign the same hash value to all NaNs.
BUG=v8:3859
LOG=y
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/897593002
Cr-Commit-Position: refs/heads/master@{#26391}
Arrow function parameter lists are parsed as expressions. When an identifier
is found a VariableProxy is created and added to the list of unresolved
variables for the scope. When parsing a function lazily, the scope has been
already resolved, so with this patch only the VariableProxy is created,
without adding it as an unresolved variable in the scope.
BUG=v8:3501
LOG=Y
Review URL: https://codereview.chromium.org/880253004
Cr-Commit-Position: refs/heads/master@{#26328}
The whole logic in DoMul makes me cry, so I made only the minimal
change to fix the issue...
BUG=v8:451322
LOG=y
Review URL: https://codereview.chromium.org/873703002
Cr-Commit-Position: refs/heads/master@{#26261}
Also fix mjsunit/regress/regress-undefined-nan to ensure that we are
testing transfer via xmm registers by forcing the transfer to be in an
optimized function.
BUG=v8:3839
LOG=n
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/863153002
Cr-Commit-Position: refs/heads/master@{#26213}
This time we simply undo the change introduced by the PPC port for
this test. No idea why it should be necessary, and Windows XP
obviously doesn't give us that much stack, anyway.
TBR=machenbach@chromium.org
Review URL: https://codereview.chromium.org/826833003
Cr-Commit-Position: refs/heads/master@{#26093}
The test fails on XP only, so let's tentatively raise the stack limit more. We probably need to investigate what a tighter limit might be and (more importantly) what the underlying reason for the failure is.
Hopefully 1800kB is enough, we can't test this via try jobs, because we don't have XP try bots. :-/
R=machenbach@chromium.org
Review URL: https://codereview.chromium.org/791693005
Cr-Commit-Position: refs/heads/master@{#26092}
The bug would occur when we try to Reset() to a position already at the end.
This happens e.g., when the regexp ends with \u. What used to happen in that
case: 1) Advance past \ and u (to the end) (which wouldn't increase next_pos_
enough) 2) Try to parse 4 hex digits 3) When that failed, Reset() to the
position which should've been at the end but wasn't.
To be able to properly Reset() to a position at the end, we need to allow
next_pos_ to move beyond the end (since position() is next_pos_ - 1).
Minimal repro case:
var r = /foo\u/
r.test("foou") // should be true, was false.
(Note that \u not followed by 4 hex didits should be interpreted as an identity
escape. It already worked unless \u was at the end of the regexp.)
BUG=v8:3756
LOG=NO
Review URL: https://codereview.chromium.org/802313003
Cr-Commit-Position: refs/heads/master@{#25838}
