port 025d476cf5 (r32906)
original commit message:
Adds a slot for the bytecode offset to interpreter stack frames and
saves it on calls, and restores after calls.
Also fixes RawMachineAssembler::Return() to call MergeControlToEnd.
BUG=
Review URL: https://codereview.chromium.org/1535613003
Cr-Commit-Position: refs/heads/master@{#32922}
Port 2c75e3d2ab
Original commit message:
We can no longer just walk the prototype chain without doing proper access-checks. When installing a proxy as the __proto__ of the global object we might accidentally end up invoking cross-realm code without access-checks (see proxies-cross-realm-ecxeption.js).
BUG=
Review URL: https://codereview.chromium.org/1526253006
Cr-Commit-Position: refs/heads/master@{#32921}
Port 97161a29ed
Original commit message:
TryTruncateFloat32ToUint64 converts a float32 to a uint64. Additionally it
provides an optional second return value which indicates whether the conversion
succeeded (i.e. float32 value was within uint64 range) or not.
Additionally I fixed a bug on x64 and mips64 in the implementation of
TryTruncateFloat64ToUint64. Cases where the input value was between -1 and 0
were handled incorrectly.
R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1533613002
Cr-Commit-Position: refs/heads/master@{#32919}
Port bb2a830deb
Port 56673804e0
Original commit messages:
MachineType is now a class with two enum fields:
- MachineRepresentation
- MachineSemantic
Both enums are usable on their own, and this change switches some places
from using MachineType to use just MachineRepresentation. Most notably:
- register allocator now uses just the representation.
- Phi and Select nodes only refer to representations.
Store nodes use only MachineRepresentation, not MachineType.
R=jarin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1523373003
Cr-Commit-Position: refs/heads/master@{#32916}
Port 28261daa47
Original commit message:
This operator now provides a second output which indicates whether the
conversion from float32 to int64 was successful or not. The second output
returns 0 if the conversion fails, or something else if the conversion succeeds.
The second output can be ignored, which means that the operator can be used the
same as the original operator.
R=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1530273002
Cr-Commit-Position: refs/heads/master@{#32914}
Adds support for loading and storing lookup variables.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1524803003
Cr-Commit-Position: refs/heads/master@{#32913}
This change adds support for local control flow when building graphs
from bytecode. The change ensures loop emitted from the bytecode
generator are in natural order so the only back branches are for loops.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1502243002
Cr-Commit-Position: refs/heads/master@{#32911}
If many threads use the same Isolate (or many Isolates) and then
terminate, their PerIsolateThreadData objects are never cleaned
up, resulting in a slow memory leak and, worse, the
PerIsolateThreadData chain getting larger and larger, adversely
affecting performance.
In this situation, embedders will now be encouraged to apply
DiscardThreadSpecificMetadata against any Isolate a thread is
done with, especially if the thread is about to terminate.
Note that it is harmless to run DiscardThreadSpecificMetadata
against an Isolate for which a thread has no thread data and
per-Isolate thread data can be reestablished if a thread starts
using an Isolate again after running DiscardThreadSpecificMetadata
against it.
It is, however, an embedder error to run
DiscardThreadSpecificMetadata against an Isolate in thread with a
Locker for the Isolate in the stack or against an Entered Isolate.
This change cannot cause any change in behavior in existing apps
as the only added coded can only be reached via the new
DiscardThreadSpecificMetadata method.
R=Jakob, jochen
BUG=
Review URL: https://codereview.chromium.org/1522703002
Cr-Commit-Position: refs/heads/master@{#32909}
Adds a slot for the bytecode offset to interpreter stack frames and
saves it on calls, and restores after calls.
Also fixes RawMachineAssembler::Return() to call MergeControlToEnd.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1512543002
Cr-Commit-Position: refs/heads/master@{#32906}
We can no longer just walk the prototype chain without doing proper access-checks. When installing a proxy as the __proto__ of the global object we might accidentally end up invoking cross-realm code without access-checks (see proxies-cross-realm-ecxeption.js).
Review URL: https://codereview.chromium.org/1521953002
Cr-Commit-Position: refs/heads/master@{#32903}
We must print "[object Array]" for proxies that satisfy Array.isArray.
Cosmetic change on the side: move ObjectProtoToString from JSObject to Object
since it deals with arbitrary objects.
R=adamk@chromium.org, verwaest@chromium.org
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1526023002
Cr-Commit-Position: refs/heads/master@{#32902}
Introduce JSCreateIterResultObject operator, as a way to optimize the
%_CreateIterResultObject intrinsic, which is used to provide uniform,
non-polymorphic result objects for iterators (and generators). We
cannot utilize the existing JSCreate operator here, because there's no
constructor function for iterator result objects (as required by the
spec).
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1531753002
Cr-Commit-Position: refs/heads/master@{#32901}
Tests for
* aborting a full page.
* partially aborting a page.
* partially aborting a page with pointers between aborted pages.
* partially aborting a page with store buffer entries.
Also introduces force_oom() which prohibits a old space to
expand
BUG=chromium:524425
LOG=N
CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel,v8_linux_nosnap_dbg,v8_win_nosnap_shared_rel,v8_win_nosnap_shared_compile_rel
Review URL: https://codereview.chromium.org/1518803005
Cr-Commit-Position: refs/heads/master@{#32899}
The problem is this: when stepping over a recursive function call,
the recursive function is flooded with one-shot break points so that
we break after the call, but since the callee is the same function,
the callee is also flooded, resulting a break in the callee. That
however would have been a "step in" instead of "step over".
The original solution was to recognize this by comparing FP. If we
end up in Debug::Break, we still have to check the current FP against
the remembered FP to see whether we are on the same stack height.
If we are deeper, then it's not a "step over", and we do not trigger
a debug break event. In that case, we queue up the step-over, and
temporarily step out until we hit the desired stack height. Note that
in order to step out, we flood the caller, which in our example is
the same function as the callee. So we break at every flooded break
location, and comparing with FP to make sure we stepped out prevents
us from triggering debug break events.
The new solution simply ignores breaks when the FP compare fails.
We simply carry on until we hit a break where the FP compare succeeds.
There is no need to do a step out. The number of calls to Debug::Break
that do not trigger a debug break event due to failing FP compare is
the same. But the code is a lot easier to read.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1527253002
Cr-Commit-Position: refs/heads/master@{#32897}
While not really fitting our directory layout, the DEPS entry needs to
be at exactly the same position as it is in chromium, otherwise either
standalone or chromium build won't work :-/
BUG=none
R=machenbach@chromium.org
LOG=y
Review URL: https://codereview.chromium.org/1526843004
Cr-Commit-Position: refs/heads/master@{#32896}
The code generation for pushing call parameters on the stack does not
distinguish between float32 and float64 parameters because both are
stored in the same registers. Therefore float32 parameters require two
words on the stack. The wasm linkage, however, only considered one word
on the stack for float32 parameters, which caused the problem that
float32 parameters were not located correctly on the stack. I fixed the
problem by considering two words for float32 parameters on the stack.
R=bradnelson@chromium.org
Review URL: https://codereview.chromium.org/1529773003
Cr-Commit-Position: refs/heads/master@{#32893}
Fix invalid usage of layout_descriptor() function on 32-bit arch's,
which doesn't perform necessary checks. Test failure is observed only on
mips32 big-endian, and on mips32 little-endian as an alignment issue,
but the problem appears to be generic for all 32-bit arch's.
TEST=test/mjsunit/es6/classes-subclass-builtins.js
BUG=
Review URL: https://codereview.chromium.org/1522203004
Cr-Commit-Position: refs/heads/master@{#32887}
The TypeOfStub didn't test the undetectable bit properly if the instance
was also callable, and therefore returned "object" for document.all
(which is both undetectable and callable).
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
R=yangguo@chromium.org
BUG=chromium:567998
LOG=n
Committed: https://crrev.com/02cc310370df7e51ac4f705038820066fdfd0cdc
Cr-Commit-Position: refs/heads/master@{#32852}
Review URL: https://codereview.chromium.org/1527863003
Cr-Commit-Position: refs/heads/master@{#32883}
If JSCreate (which corresponds to %NewObject) would ever trigger a lazy
deopt, we would deopt after the constructor call, skipping all the
initialization and what else in the constructor function, which is
wrong. Instead we can use the eager bailout point right before the
constructor function, because allocation is not observable and so we can
safely repeat the %NewObject in case of lazy bailout.
R=yangguo@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1530583004
Cr-Commit-Position: refs/heads/master@{#32880}
With the handle canonicalization we can now easily cache heap constant
nodes based on the location of the HeapObject handle location.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1523323005
Cr-Commit-Position: refs/heads/master@{#32876}
The regression the bug tracks (see the bug link) appears to
be due to identical gap moves in the predecessors of a block
not being moved to the common successor. This CR fixes one
reason that is happening.
BUG=chromium:549262
LOG=n
Review URL: https://codereview.chromium.org/1523393003
Cr-Commit-Position: refs/heads/master@{#32874}
Rolling v8/third_party/icu to 8d342a405be5ae8aacb1e16f0bc31c3a4fbf26a2
Rolling v8/tools/clang to 6261565695263bd878edd055e81ecc5e989711d6
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1529973004
Cr-Commit-Position: refs/heads/master@{#32873}