Reason for revert:
Failing on Win 32bit nosnap:
https://chromegw.corp.google.com/i/client.v8/builders/V8%20Win32%20-%20nosnap%20-%20shared/builds/10602
Original issue's description:
> [cctest] Add tests for aborting compaction of pages
>
> 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
TBR=ulan@chromium.org,hpayer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:524425
Review URL: https://codereview.chromium.org/1514603008
Cr-Commit-Position: refs/heads/master@{#32785}
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 ShouldForceOOM() which prohibits a PagedSpace from expanding.
Compaction spaces refer to the corresponding actual space.
BUG=chromium:524425
LOG=N
Review URL: https://codereview.chromium.org/1511933002
Cr-Commit-Position: refs/heads/master@{#32783}
Reason for revert:
[Sheriff] This seems to break chromium runhooks for android:
https://build.chromium.org/p/client.v8.fyi/builders/Android%20Builder/builds/1794
Original issue's description:
> MIPS: Enable v8 compilation with CLANG.
>
> Updated toolchain.gypi to support v8 using CLANG on MIPS. These changes
> include using integrated assembler with CLANG, and disabling options
> used by GCC which are not supported by CLANG.
>
> TEST=
> BUG=
>
> Committed: https://crrev.com/0bae3c393575de4503cb179faa220e597e35dd8f
> Cr-Commit-Position: refs/heads/master@{#32780}
TBR=paul.lind@imgtec.com,akos.palfi@imgtec.com,balazs.kilvady@imgtec.com,ivica.bogosavljevic@imgtec.com,jkummerow@chromium.org,Ilija.Pavlovic@imgtec.com,Ilija.Pavlovic@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1520823002
Cr-Commit-Position: refs/heads/master@{#32781}
Updated toolchain.gypi to support v8 using CLANG on MIPS. These changes
include using integrated assembler with CLANG, and disabling options
used by GCC which are not supported by CLANG.
TEST=
BUG=
Review URL: https://codereview.chromium.org/1519493002
Cr-Commit-Position: refs/heads/master@{#32780}
No need to have an indirection to get to the initial JSArray maps from
the native context; we only cache the fast elements maps anyway, so
those could live on the native context directly. This will also
integrate nicely with the load/store propagation in TurboFan (once we
propagate the immutable flag for FieldAccess as well).
Drive-by-fix: Also don't embed any of the initial JSArray maps in
TurboFan generated code when allocating a new JSArray, but instead
always load the appropriate map from the native context. This way
we ensure that we never leak a reference to one of those maps and
its as efficient as embedding a constant map.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1516433005
Cr-Commit-Position: refs/heads/master@{#32779}
port bb2a830deb (r32738)
original commit message:
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.
BUG=
Review URL: https://codereview.chromium.org/1520793002
Cr-Commit-Position: refs/heads/master@{#32778}
The main impetus is to improve performance when --harmony-tostring
is enabled, thanks to using a generic property load instead of a
megamorphic IC.
This also reduces duplication, as the API function
v8::Object::ObjectProtoToString can share the runtime implementation.
The only functional change in this patch is to drop an accidental difference
between the JS and API implementations: the arguments object should toString
as "[object Arguments]". The JS side was corrected in
https://code.google.com/p/v8/source/detail?r=3279, but the API version was
missed in that patch.
BUG=chromium:555127, v8:3502
LOG=n
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1509533003
Cr-Commit-Position: refs/heads/master@{#32777}
Rolling v8/buildtools to 68e3c238a5ab347436762cb929316aa55ca72563
Rolling v8/tools/clang to 3a1510ccbc295798602abbbffcf61065704e8acb
TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1516193002
Cr-Commit-Position: refs/heads/master@{#32776}
If we model them as memory operands ("SpillOperands"), as we
currently do, they are treated by the register allocator as being defined
in memory, so spilling them up to the first use requiring them in a
register is free.
That's not the case for context and function marker. They come in
registers, and the frame construction also pushes them on the stack.
This conflicts with the goals of frame elision: the allocator should avoid
eagerly spilling them, which would force a frame construction; also,
their not being spilled, should frame elision succeed for the first block,
means modeling them as spill operands incorrect.
The natural choice would be to fully decouple their spilling from frame
construction, and let the register allocator spill them. That means they
need to be presented to the register allocator as vanilla live ranges,
with pre-assigned spill slots.
The main challenge there is that not all instructions (mainly, stack checks) list their dependency on these ranges being spilled. In this
change, we change the model but leave the frame construction as-is.
This has the benefit that it unblocks frame elision, but has the drawback
that we may see double spills in the case where these live ranges spill
only in deferred blocks. I plan to enable frame elision next, after which
tackle this issue with spilling.
BUG= v8:4533
LOG=N
Review URL: https://codereview.chromium.org/1501363002
Cr-Commit-Position: refs/heads/master@{#32775}
This patch removes Promise functions and methods which are absent
from the ES2015 specification when the --es-staging flag is on.
The patch is being relanded after being reverted due to an
unrelated bug. This version is slightly different as promise_chain
is installed on the context regardless of the flag value, so that
the Promise::Chain API continues to work until it is deprecated.
BUG=v8:3237
R=rossberg
LOG=Y
Review URL: https://codereview.chromium.org/1513873002
Cr-Commit-Position: refs/heads/master@{#32772}
There's at least one case of a time zone alias: Asia/Kathmandu aliases
Asia/Katmandu. ICU seems to normalize to the (deprecated) latter choice.
V8 internationalization choked on this change; this patch interprets
ICU's output more precisely and allows it.
BUG=chromium:487322
R=jungshik,adamk
LOG=Y
Review URL: https://codereview.chromium.org/1509273007
Cr-Commit-Position: refs/heads/master@{#32769}
Without this fix, AssignmentExpressions that happen to be arrow functions
would lead to unbalanced Enter/Leave calls on the fni_, causing thrashing
while trying to infer function names. Symptoms include slow parsing
or OOM (when we create too many AstConsStrings).
To try to keep this from happening in the future, added an RAII helper
class to handle Entering/Leaving FNI state.
The included regression test crashes on my workstation without the patch.
Note that it's too slow in debug mode (as well as under TurboFan),
so I've skipped it there.
BUG=v8:4595
LOG=y
Review URL: https://codereview.chromium.org/1507283003
Cr-Commit-Position: refs/heads/master@{#32768}
An allocation can reenter type feedback code because of a triggered GC. Make
sure the vector state remains coherent at these points.
BUG=568524
LOG=N
Review URL: https://codereview.chromium.org/1517613003
Cr-Commit-Position: refs/heads/master@{#32766}
Function subclasses did not have function properties installed (name, prototype, etc.).
Now when an instance of a Function subclass is created it gets initial map that corresponds
to the language mode of the function body. The language mode dependent maps are cached as
special transitions on initial map of the subclass constructor.
BUG=v8:4597, v8:3101, v8:3330
LOG=Y
Review URL: https://codereview.chromium.org/1510753005
Cr-Commit-Position: refs/heads/master@{#32764}
We either want to add code+literals to the map, or just literals.
A recent change in the structure of the map (it now uses WeakCells)
meant that we have to be more clear about what we want to do the right
thing.
BUG=
Review URL: https://codereview.chromium.org/1516833002
Cr-Commit-Position: refs/heads/master@{#32761}
This is deprecating the ability of TurboFan to access FP-based slots
via LoadField and StoreField nodes. The corresponding constructors for
FieldAccess tuples are being removed.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1512243003
Cr-Commit-Position: refs/heads/master@{#32760}
This will help us to instantiate AccessorPair's getters and setters only when they are needed.
BUG=
Review URL: https://codereview.chromium.org/1510483002
Cr-Commit-Position: refs/heads/master@{#32759}
Reason for revert:
Meeh. Now "V8 Linux - gcmole" bot has issues; apparently due to a somewhat exotic builder configuration.
Original issue's description:
> Re-land FastAccessorBuilder.
>
> ... using the RawMachineAssembler and the work in crrev.com/1407313004.
>
> The original change collided with crrev.com/1513543003.
>
> BUG=chromium:508898
> LOG=Y
>
> Committed: https://crrev.com/515d9ccd8e6df7bf2ca01e2a55aaad30226399e1
> Cr-Commit-Position: refs/heads/master@{#32742}
>
> patch from issue 1474543004 at patchset 260001 (http://crrev.com/1474543004#ps260001)
>
> Committed: https://crrev.com/ee5c38d7db907ff86dd4049721c0cb4bc90a6c4d
> Cr-Commit-Position: refs/heads/master@{#32753}
TBR=epertoso@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:508898
Review URL: https://codereview.chromium.org/1517683002
Cr-Commit-Position: refs/heads/master@{#32754}
Removes the dummy control and effect edges from the RMA Call nodes. This
requires a change to the node matchers to allow them to cope with nodes
which don't have control or effect matchers.
Review URL: https://codereview.chromium.org/1518673002
Cr-Commit-Position: refs/heads/master@{#32752}
When the reviver returns undefined, the property in question must be deleted
even for arrays. So far this only happened for non-array objects.
Also change the property enumeration to be spec-conformant, which is observable when the reviver modifies its "this" object directly. There are a few further issues that need to be addressed in a separate CL.
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1506933003
Cr-Commit-Position: refs/heads/master@{#32750}
Nowadays, representation inference and simplified lowering can insert the
right truncations based on the use.
Review URL: https://codereview.chromium.org/1512243002
Cr-Commit-Position: refs/heads/master@{#32747}
... using the RawMachineAssembler and the work in cl/1407313004
BUG=chromium:508898
LOG=Y
Review URL: https://codereview.chromium.org/1474543004
Cr-Commit-Position: refs/heads/master@{#32742}
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.
Review URL: https://codereview.chromium.org/1513543003
Cr-Commit-Position: refs/heads/master@{#32738}
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.
I implement the new operator on x64, arm64, and mips64. @v8-ppc-ports, can you
please take care of the ppc64 implementation of the second output?
R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com
Review URL: https://codereview.chromium.org/1504363002
Cr-Commit-Position: refs/heads/master@{#32737}
