update.sh is gone in chromium, and using update.py will do the right
thing both before and after the deletion in chromium (previously,
update.py used to call update.sh internally on non-win).
This also has the benefit of working on Windows.
No intended behavior change.
BUG=chromium:494442
LOG=n
Review URL: https://codereview.chromium.org/1495653002
Cr-Commit-Position: refs/heads/master@{#32529}
This hackily disambiguates multiple calls for the iterator protocols in ForOf / Yield* by adding -2 / -1 to the pos.
BUG=v8:3953
LOG=y
Review URL: https://codereview.chromium.org/1491923003
Cr-Commit-Position: refs/heads/master@{#32527}
While execution will not return to this location, stack iteration
logic will attempt to find the code object associated with the return
address. This makes sure that it maps to the correct object and not
to the one immediately following it in memory.
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
Review URL: https://codereview.chromium.org/1490343002
Cr-Commit-Position: refs/heads/master@{#32526}
Split out of PropertyAttributes, and used for all filtering purposes.
Also moved PropertyAttributes into the v8::internal:: namespace.
No change in behavior intended.
Review URL: https://codereview.chromium.org/1492653004
Cr-Commit-Position: refs/heads/master@{#32525}
Also remove the ResultMode from ToBooleanStub and always return true or
false and use the same mechanism in fullcodegen. This is in preparation
for adding ToBoolean hints to TurboFan.
Drive-by-fix: We can use the power of the ToBooleanIC in TurboFan now
that the ResultMode is gone (and the runtime always returns true or
false from the miss handler).
R=mstarzinger@chromium.org
BUG=v8:4583
LOG=n
Review URL: https://codereview.chromium.org/1491223002
Cr-Commit-Position: refs/heads/master@{#32524}
Reason for revert:
Speculative revert for crashing Canary.
Original issue's description:
> Reland of [heap] Refactor evacuation for young and old gen into visitors. (patchset #1 id:1 of https://codereview.chromium.org/1483393002/ )
>
> Reason for revert:
> Reland after fixing the potential root cause of the canary crasher.
>
> Original issue's description:
> > Revert of [heap] Refactor evacuation for young and old gen into visitors. (patchset #5 id:80001 of https://codereview.chromium.org/1470253002/ )
> >
> > Reason for revert:
> > Still investigating bad canary.
> >
> > Original issue's description:
> > > [heap] Refactor evacuation for young and old gen into visitors.
> > >
> > > Create a visitor for evacuating objects for young and old generation. This is
> > > the first step of preparing a task to process, both, newspace and oldspace
> > > pages in parallel.
> > >
> > > BUG=chromium:524425
> > > LOG=N
> > >
> > > Committed: https://crrev.com/138d9bae5d7014e0d205634a49b5eac3697744c8
> > > Cr-Commit-Position: refs/heads/master@{#32349}
> >
> > TBR=mlippautz@chromium.org
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=chromium:524425
> >
> > Committed: https://crrev.com/aa24a3135ec308e1f84bce334844caf0cae2437a
> > Cr-Commit-Position: refs/heads/master@{#32462}
>
> TBR=mlippautz@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:524425
>
> Committed: https://crrev.com/120b640dfce5f02cecc5af72ca0b2b3b93ce8652
> Cr-Commit-Position: refs/heads/master@{#32500}
TBR=hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425
Review URL: https://codereview.chromium.org/1495583002
Cr-Commit-Position: refs/heads/master@{#32522}
Reason for revert:
Still failing on GC stress
https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/690
Original issue's description:
> Reland of "[heap] Clean up stale store buffer entries for aborted pages."
>
> This reverts commit d4fc4a8cad.
>
> 1. Let X be the aborted slot (slot in an evacuated object in an aborted page)
> 2. Assume X contains pointer to Y and Y is in the new space, so X is in the
> store buffer.
> 3. Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
> 4. The current mark-sweep finishes. The slot X is in free space and is also in
> the store buffer.
> 5. A string of length 9 "abcdefghi" is allocated in the new space. The string
> looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
> previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
> object before.
> 6. Scavenge happens.
> 7. Slot X is still in free space and in store buffer. [It causes scavenge of
> the object Y in
> store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
> it is not important].
> 8. Our string is promoted and is allocated over the slot X, such that NNNNNNNi
> is written in X.
> 9. The scavenge finishes.
> 9. Another scavenge starts.
> 10. We crash in
> store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
> processing slot X, because it doesn't point to valid map.
>
> BUG=chromium:524425, chromium:564498
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org
>
> Committed: https://crrev.com/fc6ff534003480e49dc481d9c665e961ab709c02
> Cr-Commit-Position: refs/heads/master@{#32514}
TBR=hpayer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425, chromium:564498
Review URL: https://codereview.chromium.org/1492823002
Cr-Commit-Position: refs/heads/master@{#32520}
We can constant fold %_IsJSReceiver(x) based on whether x is always a
receiver or can never be a receiver. This is important as
%_IsJSReceiver is inserted by the JSInliner.
R=jarin@chromium.org
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1486383003
Cr-Commit-Position: refs/heads/master@{#32519}
The new step-in implementation no longer tries to predict the step-in
target, so we don't need the arguments count nor call type anymore.
R=verwaest@chromium.org
Review URL: https://codereview.chromium.org/1484893003
Cr-Commit-Position: refs/heads/master@{#32516}
port 4f4947898d (r32262)
original commit message:
The Float32RoundUp operator rounds float32 numbers towards infinity.
The operator is currently implemented on x64, ia32, arm, and arm64.
BUG=
Review URL: https://codereview.chromium.org/1491843003
Cr-Commit-Position: refs/heads/master@{#32515}
This reverts commit d4fc4a8cad.
1. Let X be the aborted slot (slot in an evacuated object in an aborted page)
2. Assume X contains pointer to Y and Y is in the new space, so X is in the
store buffer.
3. Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4. The current mark-sweep finishes. The slot X is in free space and is also in
the store buffer.
5. A string of length 9 "abcdefghi" is allocated in the new space. The string
looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
object before.
6. Scavenge happens.
7. Slot X is still in free space and in store buffer. [It causes scavenge of
the object Y in
store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
it is not important].
8. Our string is promoted and is allocated over the slot X, such that NNNNNNNi
is written in X.
9. The scavenge finishes.
9. Another scavenge starts.
10. We crash in
store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
processing slot X, because it doesn't point to valid map.
BUG=chromium:524425, chromium:564498
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
Review URL: https://codereview.chromium.org/1494503004
Cr-Commit-Position: refs/heads/master@{#32514}
* Add a sibling interface to InterpreterAssembler called
CodeStubAssembler which provides a wrapper around the
RawMachineAssembler and is intented to make it easy to build
efficient cross-platform code stubs. Much of the implementation
of CodeStubAssembler is shamelessly stolen from the
InterpreterAssembler, and the idea is to eventually merge the
two interfaces somehow, probably moving the
InterpreterAssembler interface over to use the
CodeStubAssembler. Short-term, however, the two interfaces
shall remain decoupled to increase our velocity developing the
two systems in parallel.
* Implement the StringLength stub in TurboFan with the new
CodeStubAssembler. Replace and remove the old Hydrogen-stub
version.
* Remove a whole slew of machinery to support JavaScript-style
code stub generation, since it ultimately proved unwieldy,
brittle and baroque. This cleanup includes removing the shared
code stub context, several example stubs and a tangle of build
file changes.
BUG=v8:4587
LOG=n
Review URL: https://codereview.chromium.org/1475953002
Cr-Commit-Position: refs/heads/master@{#32508}
The main part of the Proxy constructor was already in C++, there's
actually no point in keeping a JavaScript wrapper.
R=cbruni@chromium.org
BUG=v8:1543
LOG=n
Review URL: https://codereview.chromium.org/1491893002
Cr-Commit-Position: refs/heads/master@{#32507}
Reason for revert:
Not completely correct fix.
Original issue's description:
> [heap] Clean up stale store buffer entries for aborted pages.
>
> 1. Let X be the aborted slot (slot in an evacuated object in an aborted page)
> 2. Assume X contains pointer to Y and Y is in the new space, so X is in the
> store buffer.
> 3. Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
> 4. The current mark-sweep finishes. The slot X is in free space and is also in
> the store buffer.
> 5. A string of length 9 "abcdefghi" is allocated in the new space. The string
> looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
> previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
> object before.
> 6. Scavenge happens.
> 7. Slot X is still in free space and in store buffer. [It causes scavenge of
> the object Y in
> store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
> it is not important].
> 8. Our string is promoted and is allocated over the slot X, such that NNNNNNNi
> is written in X.
> 9. The scavenge finishes.
> 9. Another scavenge starts.
> 10. We crash in
> store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
> processing slot X, because it doesn't point to valid map.
>
> BUG=chromium:524425,chromium:564498
> LOG=N
> R=hpayer@chromium.org, ulan@chromium.org
>
> Committed: https://crrev.com/2e7eea4aef3403969fe885e30f892d46253b3572
> Cr-Commit-Position: refs/heads/master@{#32495}
TBR=hpayer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425,chromium:564498
Review URL: https://codereview.chromium.org/1489243004
Cr-Commit-Position: refs/heads/master@{#32504}
Reason for revert:
Reland after fixing the potential root cause of the canary crasher.
Original issue's description:
> Revert of [heap] Refactor evacuation for young and old gen into visitors. (patchset #5 id:80001 of https://codereview.chromium.org/1470253002/ )
>
> Reason for revert:
> Still investigating bad canary.
>
> Original issue's description:
> > [heap] Refactor evacuation for young and old gen into visitors.
> >
> > Create a visitor for evacuating objects for young and old generation. This is
> > the first step of preparing a task to process, both, newspace and oldspace
> > pages in parallel.
> >
> > BUG=chromium:524425
> > LOG=N
> >
> > Committed: https://crrev.com/138d9bae5d7014e0d205634a49b5eac3697744c8
> > Cr-Commit-Position: refs/heads/master@{#32349}
>
> TBR=mlippautz@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:524425
>
> Committed: https://crrev.com/aa24a3135ec308e1f84bce334844caf0cae2437a
> Cr-Commit-Position: refs/heads/master@{#32462}
TBR=mlippautz@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425
Review URL: https://codereview.chromium.org/1493523003
Cr-Commit-Position: refs/heads/master@{#32500}
MIPS R6 introduced new behavior for handling of NaN values
for TRUNC, FLOOR, CEIL and CVT instructions. Adding support for
the new behavior in MIPS and MIPS64 simulators. Fixing tests
for MIPS and MIPS64 to align them with the new behavior.
BUG=
Review URL: https://codereview.chromium.org/1488613007
Cr-Commit-Position: refs/heads/master@{#32499}
This is the first part of escape analysis for turbofan.
At the moment, there is no deopt support, and support
for loops is partial (only binary Phis are handled).
The CL includes 4 unittests.
There are also 8 new mjsunit tests, some of which are
skiped as they require features not yet implemented.
BUG=v8:4586
LOG=n
Review URL: https://codereview.chromium.org/1457683003
Cr-Commit-Position: refs/heads/master@{#32498}
non-constructors are not allowed to have initial maps. The optimizing compilers used to add initial maps unconditionally to functions used as right-hand-side in instanceof.
BUG=
Review URL: https://codereview.chromium.org/1490003003
Cr-Commit-Position: refs/heads/master@{#32497}
1. Let X be the aborted slot (slot in an evacuated object in an aborted page)
2. Assume X contains pointer to Y and Y is in the new space, so X is in the
store buffer.
3. Store buffer rebuilding will not filter out X (it checks InNewSpace(Y)).
4. The current mark-sweep finishes. The slot X is in free space and is also in
the store buffer.
5. A string of length 9 "abcdefghi" is allocated in the new space. The string
looks like |MAP|LENGTH|hgfedcba|NNNNNNNi| in memory, where NNNNNNN is
previous garbage. Let's assume that NNNNNNN0 was pointing to a new space
object before.
6. Scavenge happens.
7. Slot X is still in free space and in store buffer. [It causes scavenge of
the object Y in
store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject). But
it is not important].
8. Our string is promoted and is allocated over the slot X, such that NNNNNNNi
is written in X.
9. The scavenge finishes.
9. Another scavenge starts.
10. We crash in
store_buffer()->IteratePointersToNewSpace(&Scavenger::ScavengeObject) when
processing slot X, because it doesn't point to valid map.
BUG=chromium:524425,chromium:564498
LOG=N
R=hpayer@chromium.org, ulan@chromium.org
Review URL: https://codereview.chromium.org/1493653002
Cr-Commit-Position: refs/heads/master@{#32495}
port 74434403f6 (r32261)
original commit message:
I implemented the optional Float32RoundDown operator on x64, ia32, arm,
and arm64.
For arm I also had to adjust the simulator.
BUG=
Review URL: https://codereview.chromium.org/1490113003
Cr-Commit-Position: refs/heads/master@{#32492}
Sanitize ConstructStub handling and add a test case to ensure that the
Symbol constructor is using the correct context.
R=jarin@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1489323002
Cr-Commit-Position: refs/heads/master@{#32491}
port dffecf31fc (r32005)
original commit message:
The TiesEven rounding mode rounds float64 numbers to the nearest
integer. If there are two nearest integers, then the number is rounded
to the even one. This is the default rounding mode according to
IEEE~754.
I implemented the operator on ia32, x64, arm, arm64, mips, and mips64.
I think there is a bug in the current implementation of the ppc
simulator, which kept me from implementing the operator on ppc.
According to my understanding of the ppc instruction manual, the FRIN
instruction provides the right behavior for Float64RoundTiesEven. In the
simulator, however, FRIN provides a different semantics. If there are
two nearest integers, then the simulator returns the one which is
further away form 0.
BUG=
Review URL: https://codereview.chromium.org/1486323003
Cr-Commit-Position: refs/heads/master@{#32490}
port d2f78c6b79 (r32476)
original commit message:
This becomes visible if an exception is thrown by the constructor.
We do this on "new Array(3.5)", throwing a RangeError.
BUG=
Review URL: https://codereview.chromium.org/1491153002
Cr-Commit-Position: refs/heads/master@{#32489}
port 66d5a9df62 (r32452)
original commit message:
CallIC and CallConstructStub look so alike, at least in the feedback they gather even if the implementation differs...and CallIC has such a nice way of surfacing the feedback (CallICNexus), that there
BUG=
Review URL: https://codereview.chromium.org/1491063003
Cr-Commit-Position: refs/heads/master@{#32488}
Rolling v8/build/gyp to e2313c02ad7b6d589b38fe578f5d39970a9bbc20
Rolling v8/tools/clang to 3cc3dac50b26c67176bfed187a300741f31651bf
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1491133002
Cr-Commit-Position: refs/heads/master@{#32485}
port 1389b9f53c (r32004)
original commit message:
I implemented it on x64, ia32, arm, arm64, mips, mips64, and ppc.
BUG=
Review URL: https://codereview.chromium.org/1488993002
Cr-Commit-Position: refs/heads/master@{#32484}
We currently use the outdated contexts list provided by the serializer
to update the receiver (the global proxy) in script contexts. However,
this is not actually necessary, since the global proxy is passed to the
deserializer and replaced as we deserialize.
Originally, the outdated contexts list is to update the global object
field in contexts. This was necessary since at the time the deserializer
creates the native context, the global object has not yet been created.
But the global proxy already exists.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1488873004
Cr-Commit-Position: refs/heads/master@{#32483}
