Adds a scavenge GC pass that collects unmodified references instead of
processing object groups. This mode can be controlled by setting
FLAG_scavenge_reclaim_unmodified_objects. By default this is turned off.
Also, modified a test case to suit the handle the new GC pass.
BUG=v8:4421
LOG=N
Review URL: https://codereview.chromium.org/1410593005
Cr-Commit-Position: refs/heads/master@{#31599}
This patch switches sloppy-mode code from legacy const semantics
to ES2015 semantics. It is unknown how much of the web will be
broken by this; likely the patch will have to be reverted before
a branch happens.
BUG=v8:3739
LOG=Y
R=rossberg,adamk
Review URL: https://codereview.chromium.org/1420223003
Cr-Commit-Position: refs/heads/master@{#31525}
Both the JSTypeFeedbackSpecializer and the JSTypeFeedbackLowering is
dead code by now, since the more general JSNativeContextSpecialization
deals with the property/global load/store type feedback in a way that
also interacts properly with inlining.
BUG=v8:4470
LOG=n
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1407913003 .
Cr-Commit-Position: refs/heads/master@{#31462}
This stages the general purpose inlining mechanism in TurboFan and
also disables the remaining tests that still fail. We do this to get
test coverage early and to avoid regressing inlining as we go along.
R=jarin@chromium.org,mstarzinger@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1419623002
Cr-Commit-Position: refs/heads/master@{#31406}
This stages the general purpose inlining mechanism in TurboFan and also
disables the remaining tests that still fail. We do this to get test
coverage early and to avoid regressing inlining as we go along.
R=bmeurer@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1412703002
Cr-Commit-Position: refs/heads/master@{#31386}
Reason for revert:
This still breaks Inbox.
Original issue's description:
> Stage --harmony_sloppy_function
>
> This patch turns on ES2015-style function hoisting semantics in
> staging. --harmony_sloppy_function was previously staged, leading
> to a number of bugs being filed and the staging being reversed;
> important bugs have been fixed, so it is time to try again.
>
> R=adamk
> LOG=Y
> BUG=v8:4285
>
> Committed: https://crrev.com/333e27fd99f8187c97e62b9538529900f0a30668
> Cr-Commit-Position: refs/heads/master@{#31190}
TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4285
Review URL: https://codereview.chromium.org/1402763003
Cr-Commit-Position: refs/heads/master@{#31206}
This patch turns on ES2015-style function hoisting semantics in
staging. --harmony_sloppy_function was previously staged, leading
to a number of bugs being filed and the staging being reversed;
important bugs have been fixed, so it is time to try again.
R=adamk
LOG=Y
BUG=v8:4285
Review URL: https://codereview.chromium.org/1393423002
Cr-Commit-Position: refs/heads/master@{#31190}
Add a flag to explicitly filter scripts in ignition and use it for the test262
variant. The previous approach of overloading ignition-filter meant that only
top-level code was getting compiled through ignition.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1396493002
Cr-Commit-Position: refs/heads/master@{#31164}
Introduce a new JSGlobalSpecialization advanced reducer that runs
during the initial inlining and context specialization, and specializes
the graph to the globals of the native context. Currently we assume
that we do not inline cross native context, but long-term we will grab
the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
new global load/store ICs that are currently in the workings), and then
this whole specialization will be fully compositional even across
cross-context inlining.
Note that we cannot really handle most of the stores to global object
property cells because TurboFan doesn't have a mechanism to enforce
certain representations. Also note that we cannot yet fully benefit
from the type feedback collected on the global object property cells,
because the type system cannot deal with maps in a reasonable way.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Committed: https://crrev.com/6fbf7903f94924ea066af481719898bd9667b6eb
Cr-Commit-Position: refs/heads/master@{#31139}
Review URL: https://codereview.chromium.org/1387393002
Cr-Commit-Position: refs/heads/master@{#31148}
Reason for revert:
Breaks GC stress: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/1984/steps/Bisect%20c5528ac1.Retry/logs/regress-crbug-450960
Original issue's description:
> [turbofan] Add initial support for global specialization.
>
> Introduce a new JSGlobalSpecialization advanced reducer that runs
> during the initial inlining and context specialization, and specializes
> the graph to the globals of the native context. Currently we assume
> that we do not inline cross native context, but long-term we will grab
> the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
> new global load/store ICs that are currently in the workings), and then
> this whole specialization will be fully compositional even across
> cross-context inlining.
>
> Note that we cannot really handle most of the stores to global object
> property cells because TurboFan doesn't have a mechanism to enforce
> certain representations. Also note that we cannot yet fully benefit
> from the type feedback collected on the global object property cells,
> because the type system cannot deal with maps in a reasonable way.
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
> R=jarin@chromium.org
> BUG=v8:4470
> LOG=n
>
> Committed: https://crrev.com/6fbf7903f94924ea066af481719898bd9667b6eb
> Cr-Commit-Position: refs/heads/master@{#31139}
TBR=jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4470
Review URL: https://codereview.chromium.org/1390073004
Cr-Commit-Position: refs/heads/master@{#31144}
Introduce a new JSGlobalSpecialization advanced reducer that runs
during the initial inlining and context specialization, and specializes
the graph to the globals of the native context. Currently we assume
that we do not inline cross native context, but long-term we will grab
the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
new global load/store ICs that are currently in the workings), and then
this whole specialization will be fully compositional even across
cross-context inlining.
Note that we cannot really handle most of the stores to global object
property cells because TurboFan doesn't have a mechanism to enforce
certain representations. Also note that we cannot yet fully benefit
from the type feedback collected on the global object property cells,
because the type system cannot deal with maps in a reasonable way.
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1387393002
Cr-Commit-Position: refs/heads/master@{#31139}
Reason for revert:
[Sheriff] Speculative revert due to crbug.com/539814
Original issue's description:
> Changed scavenge GC to collect unmodified references
>
> Added a scavenge GC pass that collects unmodified references instead of
> processing object groups. This mode can be controlled by setting
> FLAG_scavenge_remove_unmodified_objects. By default this is turned off.
> Also, modified a test case to suit the handle the new GC pass.
>
> BUG=v8:4421
> LOG=N
>
> Committed: https://crrev.com/6254019238a853c9f3c09d615ba153043f6957c7
> Cr-Commit-Position: refs/heads/master@{#31102}
TBR=jochen@chromium.org,rmcilroy@chromium.org,mythria@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4421,chromium:539814
Review URL: https://codereview.chromium.org/1388133002
Cr-Commit-Position: refs/heads/master@{#31130}
Added a scavenge GC pass that collects unmodified references instead of
processing object groups. This mode can be controlled by setting
FLAG_scavenge_remove_unmodified_objects. By default this is turned off.
Also, modified a test case to suit the handle the new GC pass.
BUG=v8:4421
LOG=N
Review URL: https://codereview.chromium.org/1358703003
Cr-Commit-Position: refs/heads/master@{#31102}
Arrow functions have been enabled by default since the 4.5 branch.
Review URL: https://codereview.chromium.org/1373633002
Cr-Commit-Position: refs/heads/master@{#31031}
The current implemention breaks sloppy mode code that uses function
declarations inside blocks at top-level. Work is ongoing on a patch
to fix this issue, but in the meantime it seems reasonable to move
the feature out of staging.
Manual revert of commit 6e07f5a75b.
R=littledan@chromium.org
BUG=chromium:535836
LOG=y
Review URL: https://codereview.chromium.org/1375213005
Cr-Commit-Position: refs/heads/master@{#31029}
This name makes it clear that the flag (also the variant in the Compiler)
is talking about specializing to the function context instead of i.e. the
native context.
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/1372513003
Cr-Commit-Position: refs/heads/master@{#30934}
It's been enabled since M45, which is now well into its stable period,
with no problems reported.
Review URL: https://codereview.chromium.org/1356793002
Cr-Commit-Position: refs/heads/master@{#30835}
Defines a new --harmony-tolength flag, and a ToLengthFlagged() runtime function,
that is used where ES6 requires ToLength(), but a pre-ES6 conversion existed
before. When the flag is disabled, the function uses TO_UINT32(), which is
the pre-ES6 behaviour. When the flag enabled, the ES6-compliant ToLength()
conversion is used.
Based on a patch initially from Diego Pino <dpino@igalia.com>
BUG=v8:3087
LOG=Y
Review URL: https://codereview.chromium.org/1309243003
Cr-Commit-Position: refs/heads/master@{#30772}
There isn't a plan to turn it on soon, so we'll take it out in favor of cleaner code.
BUG=
Review URL: https://codereview.chromium.org/1202173002
Cr-Commit-Position: refs/heads/master@{#30767}
Some pretty hacky code was used to carry out the tail-call
handler dispatch on ia32 vector stores due to a lack
of free registers. It really tanks performance. A better
approach is to use a virtual register on the isolate.
BUG=
Review URL: https://codereview.chromium.org/1336313002
Cr-Commit-Position: refs/heads/master@{#30718}
This removes the aforementioned flag which has been on by default for a
while now. Note that this does not control optimization decisions, only
the last-resort bailout in the graph builder.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1335543002
Cr-Commit-Position: refs/heads/master@{#30673}
Adds support for property store operations via Store/KeyedStore ICs. Adds the
following bytecodes:
- StoreIC
- KeyedStoreIC
The --vector_store flag is now required for --ignition.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1319833004
Cr-Commit-Position: refs/heads/master@{#30660}
- Modify js2c to accept --js and --nojs,
- modify mksnapshot to accept --startup_src
(instead of a positional parameter, so that it can be omitted),
- modify v8.gyp to use the above so that no target has multiple
output dependencies, and
- update GN to use the switches above.
(I have not succeeded in fixing the GYP->make translator to properly map
multi-output rules, so that they work as expected in all edge cases.
This CL signals defeat on that front, and instead I rewrite the GYP
file to avoid that situation in the first place.)
R=jochen@chromium.org
BUG=v8:4382
LOG=N
Review URL: https://codereview.chromium.org/1310273009
Cr-Commit-Position: refs/heads/master@{#30640}
Once a range is found to have a conflict, split around all the calls it
crosses over, since it will anyway have conflicts there, too.
Incrementally, from the last change to greedy, this change brings
overall improvement in benchmarks. In fact, except for 2 regressions
in Jetstream (splay-latency and date-format-xparb, at 6 and 7%
respectivelly), everything else is in the green or noise. Quite a few
benchmarks are over 3%, with a few (zlib, for example) in the double
digits.
Review URL: https://codereview.chromium.org/1328783002
Cr-Commit-Position: refs/heads/master@{#30579}
Move the --harmony-sloppy-let flag to staging for further testing, and
update test262 for the new passing tests. Also increase the strictness
of the parser, even in sloppy mode, to disallow "new legacy compat" for
for (let x = 5 in {}) {}
which is now a SyntaxError.
BUG=v8:3305
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1321013005
Cr-Commit-Position: refs/heads/master@{#30525}
Reason for revert:
Fails a test262 test with --always-opt.
Original issue's description:
> Stage sloppy let
>
> Move the --harmony-sloppy-let flag to staging for further testing, and
> update test262 for the new passing tests. Also increase the strictness
> of the parser, even in sloppy mode, to disallow "new legacy compat" for
>
> for (let x = 5 in {}) {}
>
> which is now a SyntaxError.
>
> BUG=v8:3305
> LOG=Y
> R=adamk
>
> Committed: https://crrev.com/07bc0117be8dc9e63ec14d5f9645c483d60a1bec
> Cr-Commit-Position: refs/heads/master@{#30515}
TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3305
Review URL: https://codereview.chromium.org/1324033002
Cr-Commit-Position: refs/heads/master@{#30518}
Move the --harmony-sloppy-let flag to staging for further testing, and
update test262 for the new passing tests. Also increase the strictness
of the parser, even in sloppy mode, to disallow "new legacy compat" for
for (let x = 5 in {}) {}
which is now a SyntaxError.
BUG=v8:3305
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1327483002
Cr-Commit-Position: refs/heads/master@{#30515}
We completely un-wired the greedy allocator to focus on the
stackchecks in loops (splintering) work. This change re-wires greedy,
still behind its flag. For now, enabling the greedy allocator disables
the stackchecks in loops feature (and range splintering), so that we are
at the baseline we left it at.
The main contribution in this change is adapting the codebase after
the live range model refactoring, whereby RegisterAllocationData's
live_ranges() contains just top-level ranges, and children are accessed
via their parents.
BUG=
Review URL: https://codereview.chromium.org/1320363002
Cr-Commit-Position: refs/heads/master@{#30492}
When encountering a "=" token in ParseAssignmentExpression, the default
parameter case is not locally distinguishable from the destructuring case.
BUG=
Review URL: https://codereview.chromium.org/1317843002
Cr-Commit-Position: refs/heads/master@{#30386}
The lack of marking this dependency led to a ClusterFuzz crash when
sloppy-function was on but not sloppy. This case does not make sense.
R=adamk
LOG=N
BUG=chromium:520891
Review URL: https://codereview.chromium.org/1316773004
Cr-Commit-Position: refs/heads/master@{#30364}
This change encompasses what is necessary to enable stack checks in loops without suffering large regressions.
Primarily, it consists of a new mechanism for dealing with deferred blocks by "splintering", rather than splitting, inside deferred blocks.
My initial change was splitting along deferred block boundaries, but the regression introduced by stackchecks wasn't resolved conclusively. After investigation, it appears that just splitting ranges along cold block boundaries leads to a greater opportunity for moves on the hot path, hence the suboptimal outcome.
The alternative "splinters" ranges rather than splitting them. While splitting creates 2 ranges and links them (parent-child), in contrast, splintering creates a new independent range with no parent-child relation to the original. The original range appears as if it has a liveness hole in the place of the splintered one. All thus obtained ranges are then register allocated with no change to the register allocator.
The splinters (cold blocks) do not conflict with the hot path ranges, by construction. The hot path ones have less pressure to split, because we remove a source of conflicts. After allocation, we merge the splinters back to their original ranges and continue the pipeline. We leverage the previous changes made for deferred blocks (determining where to spill, for example).
Review URL: https://codereview.chromium.org/1305393003
Cr-Commit-Position: refs/heads/master@{#30357}
Embedders would use these for features which must be able to be turned
off at runtime, despite being compiled into V8. They can be turned on
and off by the embedder using the --experimental_extras flag, e.g. via
v8::SetFlagsFromString.
R=yangguo@chromium.org, mlippautz@chromium.org, hpayer@chromium.org
BUG=chromium:507137
LOG=Y
Review URL: https://codereview.chromium.org/1284413002
Cr-Commit-Position: refs/heads/master@{#30260}
Bytecode generator for local assignment and basic binary operations.
Command-line flag for printing bytecodes.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1294543002
Cr-Commit-Position: refs/heads/master@{#30221}
Restricts linux perf-event code range reporting to functions only (i.e. on
stubs.) While this makes the gathered ticks less accurate, it reduces the
growth of the /tmp/perf-${pid}.map file.
BUG=v8:3453
R=hablich@chromium.org,danno@chromium.org
LOG=N
Review URL: https://codereview.chromium.org/1292743002
Cr-Commit-Position: refs/heads/master@{#30179}
This patch puts --harmony-sloppy into staging. Now that let, lexically-scoped
functions and ES2015 sloppy mode const semantics have been split off into
separate flags, the change only enables classes in sloppy mode.
BUG=v8:3305
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1288153003
Cr-Commit-Position: refs/heads/master@{#30141}
In an initial attempt to implement sloppy mode lexical bindings,
functions were made lexically scoped in sloppy mode. However, the
ES2015 spec says that they need an additional hoisted var binding,
and further, it's not clear when we'll implement that behavior
or whether it's web-compatible.
This patch splits off function block scoping into a new, separate
flag called --harmony_sloppy_function. This change will enable the
possibility of testing and shipping this feature separately from
other block scoping-related features which don't have the same risks.
BUG=v8:4285
R=adamk
LOG=N
Review URL: https://codereview.chromium.org/1282093002
Cr-Commit-Position: refs/heads/master@{#30122}
With the recent changes to the incremental marking API we can now kick off
incremental marking while respecting callback flags.
Performance neutral for smoothness.image_decoding_cases on N9 (read: does not
crash) as long as we synchronously process phantom callbacks
(kGCCallbackFlagForced).
OORT single run:
"marksweep": {
"count": 5,
"pause_min": 7.5,
"pause_max": 158.8,
"pause_avg": 97.52000000000001,
"pause_gt_10ms": 4
}
--- vs ---
"marksweep": {
"count": 5,
"pause_min": 16.2,
"pause_max": 22.1,
"pause_avg": 19.32,
"pause_gt_10ms": 5
}
The number of actual full GCs varies. The improvement manifests in reduced
maximum and average pauses.
BUG=chromium:515795
LOG=N
Review URL: https://codereview.chromium.org/1271253002
Cr-Commit-Position: refs/heads/master@{#30028}
To avoid tanking context startup performance, only the actual installation of the
JS-exposed API is flag-guarded. The remainder of the implementation still
resides in the snapshot.
Review URL: https://codereview.chromium.org/1257063003
Cr-Commit-Position: refs/heads/master@{#30017}
Added a separate flag for this, since we intend to enable it for the linear allocator as well. Currently, the option is "on" for greedy, as a point in time to enable its testing (through the greedy allocator bots).
BUG=
Review URL: https://codereview.chromium.org/1256313003
Cr-Commit-Position: refs/heads/master@{#30005}
Reason for revert:
Suspected to cause Canary crashes
Original issue's description:
> Reland^2 "Enable loads and stores to global vars through property cell shortcuts installed into parent script context".
>
> This reverts commit 362b378501.
>
> R=ishell@chromium.org
>
> Committed: https://crrev.com/440ae014e56924b52337c3747221b79283f07b81
> Cr-Commit-Position: refs/heads/master@{#29849}
TBR=ishell@chromium.org,v8-mips-ports@googlegroups.com,plind44@gmail.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/1260423002
Cr-Commit-Position: refs/heads/master@{#29905}
Reason for revert:
This CL may be the reason for the spike on memory corruption. Tentatively reverting this CL.
BUG=chromium:512780
LOG=n
Original issue's description:
> Activate preserving of optimized code map accross GCs.
>
> This enables --noflush-optimized-code-cache which allows preserving
> entries in the optimized code map accross GCs. This only applies to
> values being reachable through other paths.
>
> R=hpayer@chromium.org,hablich@chromium.org
>
> Committed: https://crrev.com/1a8776db25b63c4ce718423772d1fd13f58eeab5
> Cr-Commit-Position: refs/heads/master@{#29755}
TBR=hablich@chromium.org,mstarzinger@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1255043003
Cr-Commit-Position: refs/heads/master@{#29888}
--harmony_sloppy includes behavior to turn on sloppy mode lexical
bindings. Before this patch, it also included a way to parse let
which is likely web-incompatible (let is disallowed as an
identifier). This patch splits off the let parsing from the more
general block scoping code, so that block scoping can be developed
independently.
R=adamk
LOG=N
BUG=v8:3305
Review URL: https://codereview.chromium.org/1255013002
Cr-Commit-Position: refs/heads/master@{#29855}
This function will be used later instead of HasLowAllocationRate
to decide how many pages to compact.
BUG=chromium:502247
LOG=NO
Review URL: https://codereview.chromium.org/1254603002
Cr-Commit-Position: refs/heads/master@{#29841}
Adds basic support for generation of interpreter bytecode handler code
snippets. The InterpreterAssembler class exposes a set of low level,
interpreter specific operations which can be used to build a Turbofan
graph. The Interpreter class generates a bytecode handler snippet for
each bytecode by assembling operations using an InterpreterAssembler.
Currently only two simple bytecodes are supported: LoadLiteral0 and Return.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1239793002
Cr-Commit-Position: refs/heads/master@{#29814}
This preserves the context-independent entry in an optimized code map
across GCs when the code is considered young (i.e. less than 3 ages).
Note that any context-dependent entry for the same code will still be
flushed immediately when the respective context dies, hence context
lifetime is not increased.
R=hpayer@chromium.org
Review URL: https://codereview.chromium.org/1252463002
Cr-Commit-Position: refs/heads/master@{#29790}
This enables --noflush-optimized-code-cache which allows preserving
entries in the optimized code map accross GCs. This only applies to
values being reachable through other paths.
R=hpayer@chromium.org,hablich@chromium.org
Review URL: https://codereview.chromium.org/1217863006
Cr-Commit-Position: refs/heads/master@{#29755}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Committed: https://crrev.com/e5ed3bee99807c502fa7d7a367ec401e16d3f773
Cr-Commit-Position: refs/heads/master@{#29689}
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29712}
This CL exposes the constructor function, defines type related
information, and implements value type semantics.
It also refactors test/mjsunit/samevalue.js to test SameValue and SameValueZero.
TEST=test/mjsunit/harmony/simd.js, test/cctest/test-simd.cc
LOG=Y
BUG=v8:4124
Review URL: https://codereview.chromium.org/1219943002
Cr-Commit-Position: refs/heads/master@{#29689}
Return both --harmony-spreadcalls and --harmony-spread-arrays
to staging, in preparation for disabling those features on
the M45 branch.
There are no known bugs in spread calls, but without rest and spread
arrays it seems appropriate to leave all of them out rather than
only supporting a singular use of the '...' operator.
BUG=v8:4298
LOG=y
Review URL: https://codereview.chromium.org/1230773005
Cr-Commit-Position: refs/heads/master@{#29657}
Reason for revert:
[Sheriff] This changes lots of layout tests. See comment on CL.
Original issue's description:
> Enable loads and stores to global vars through property cell shortcuts installed into parent script context.
>
> Committed: https://crrev.com/cd61b047f1ab92c353a629556f9d3ad571ace1b1
> Cr-Commit-Position: refs/heads/master@{#29595}
TBR=verwaest@chromium.org,ishell@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1236863002
Cr-Commit-Position: refs/heads/master@{#29599}
This CL also adds hydrogen stubs for global loads and global stores, full-codegen and TurboFan now uses this machinery.
Review URL: https://codereview.chromium.org/1224793002
Cr-Commit-Position: refs/heads/master@{#29592}
The breakage to Chrome seems to be based on @@isConcatSpreadable
and turning that part off with this patch fixes the Maps Tips & Tricks
test case.
BUG=chromium:507553
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1226063002
Cr-Commit-Position: refs/heads/master@{#29545}
Conditionally including Array and TypedArray methods seems to cause
a slowdown in V8 context creation, possibly due to the new code added.
BUG=chromium:504629
R=adamk@chromium.org
LOG=Y
Review URL: https://codereview.chromium.org/1215863003
Cr-Commit-Position: refs/heads/master@{#29430}
This allows context-independent code generated by TurboFan to be cached
in the optimized code map and reused across native contexts. Note that
currently this cache is still flushed at GC time.
R=bmeurer@chromium.org,mvstanton@chromium.org
TEST=cctest/test-compiler/OptimizedCodeSharing
Review URL: https://codereview.chromium.org/1208013002
Cr-Commit-Position: refs/heads/master@{#29313}
Turning the --harmony-array flag on has been delayed behind
unrelated test failures. Now that those tests are disabled,
land the changes.
This patch fixes WebKit tests based on the new change.
R=adamk
LOG=Y
BUG=v8:3578
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1199113003
Cr-Commit-Position: refs/heads/master@{#29209}
Reasons:
- It is not used.
- It complicates code in GC.
BUG=chromium:499713
LOG=NO
Review URL: https://codereview.chromium.org/1184723002
Cr-Commit-Position: refs/heads/master@{#29027}
This allows try-catch and try-finally constructs to be separately
enabled and disabled. We plan to stage try-catch support soon.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1157863015
Cr-Commit-Position: refs/heads/master@{#28848}
Embed constant pools within their corresponding Code
objects.
This removes support for out-of-line constant pools in favor
of the new approach -- the main advantage being that it
eliminates the need to allocate and manage separate constant
pool array objects.
Currently supported on PPC and ARM. Enabled by default on
PPC only.
This yields a 6% improvment in Octane on PPC64.
R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
BUG=chromium:478811
LOG=Y
Review URL: https://codereview.chromium.org/1162993006
Cr-Commit-Position: refs/heads/master@{#28801}
Stage 1 implementation:
- Parameters can't be referenced before initialized (from left-to-right)
- SingleNameBindings only, no support for BindingPatterns
Known issues:
- Incorrect scoping (parameter expressions may reference variables declared in function body)
- Function arity is untouched
- Hole-checking needs work
- Rest parameters are broken when mixed with optional arguments
BUG=v8:2160
LOG=N
R=arv@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1127063003
Cr-Commit-Position: refs/heads/master@{#28739}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer
under the hood. It can be distinguished from an ArrayBuffer by the newly-added
is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer
and an ArrayBuffer. However, a future CL will add the Atomics API, which is
only available on an SharedArrayBuffer. All non-atomic accesses are identical
to ArrayBuffer accesses.
LOG=N
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28594}
Reason for revert:
breaks build
Original issue's description:
> Implement SharedArrayBuffer.
>
> This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
>
> Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
>
> BUG=
>
> Committed: https://crrev.com/57170bff7baf341c666252a7f6a49e9c08d51263
> Cr-Commit-Position: refs/heads/master@{#28588}
TBR=jarin@chromium.org,jochen@chromium.org,binji@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1149203003
Cr-Commit-Position: refs/heads/master@{#28589}
This adds a new external type (v8::SharedArrayBuffer) that uses a JSArrayBuffer under the hood. It can be distinguished from an ArrayBuffer by the newly-added is_shared() bit.
Currently there is no difference in functionality between a SharedArrayBuffer and an ArrayBuffer. However, a future CL will add the Atomics API, which is only available on an SharedArrayBuffer. All non-atomic accesses are identical to ArrayBuffer accesses.
BUG=
Review URL: https://codereview.chromium.org/1136553006
Cr-Commit-Position: refs/heads/master@{#28588}
This follows the logic of the load ics, in that the base extra ic state is
better encapsulated.
Introduce flag vector_stores to aid development of vector-based store ics.
BUG=
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1151253004
Cr-Commit-Position: refs/heads/master@{#28576}
This allows enabling TurboFan on a certain subset of language features
in the AstNumberingVisitor. The heuristics of when to optimize remain
unchanged, only the choice of which optimizing compiler to use changes.
R=bmeurer@chromium.org
BUG=v8:4131
LOG=N
Review URL: https://codereview.chromium.org/1155503002
Cr-Commit-Position: refs/heads/master@{#28544}
