The tail call implementation is hidden behind the --harmony-tailcalls
flag, which is off-by-default (and has been unstaged since February).
It is known to be broken in a variety of cases, including clusterfuzz
security issues (see sample Chromium issues below). To avoid letting
the implementation bitrot further on trunk, this patch removes it.
Bug: v8:4698, chromium:636914, chromium:724746
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c
Reviewed-on: https://chromium-review.googlesource.com/569069
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46651}
We only optimize functions which are already compiled, so there is no need
to ensure baseline in pipeline.cc, and since ast-graph-builder doesn't
do inlining, there are no other uses.
BUG=v8:5203, v8:6409
Change-Id: I830c8868d50363f61193a96d9a5774e059a1af0e
Reviewed-on: https://chromium-review.googlesource.com/570033
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46649}
These are no longer necessary since we only have one optimizing compiler.
Also avoid changing --turbo-filter when --no-opt is set, and instead
explicitly check both the FLAG_opt and FLAG_turbo_filter in
GetOptimizedCode to check whether optimization is disabled.
BUG=v8:6408
Change-Id: I0948f788e8ff111c08022270d86c22f848da300a
Reviewed-on: https://chromium-review.googlesource.com/568484
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46648}
This is the x64 implementation of the CL
https://codereview.chromium.org/2763593002
Original message:
[wasm][arm] Add an additional stack check for functions with big frames.
Stack overflow checks are typically implemented as part of the TurboFan
graph of a function. This means that the stack check code is executed
after frame construction. When a frame is too big, though, there may not
be enough space on the stack anymore to throw the stack overflow
exception after frame construction. With this CL we do an additional
stack check before frame construction for functions with big frames.
As discussed offline with mstarzinger, I do this change currently only
for WebAssembly.
This CL contains only the changes for arm. I will do the other platforms
in separate CLs.
R=titzer@chromium.org
Bug: v8:6318
Change-Id: Id4a8ea3ee76c37132e86a7c4e5d05d3bd86df44a
Reviewed-on: https://chromium-review.googlesource.com/565562
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46640}
... that have computed name and/or require home object.
This should give us the opportunity to implement initialization
of name and home object values in a stub.
Bug: v8:6459
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I47a1a2c185e120e86c793733cce737811f895291
Reviewed-on: https://chromium-review.googlesource.com/512802
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46638}
Removes the --ignition flag which is now on by default. Adds a
--stress-fullcodegen flag which enables running all functions supported
by fullcodegen to be compiled by fullcodegen.
This will enable moving parser internalization later when we are not
stressing fullcodegen or compiling asm.js functions.
BUG=v8:5203, v8:6409, v8:6589
Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e
Reviewed-on: https://chromium-review.googlesource.com/565569
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46635}
Additionally, drive-by add a test inspired by a worrying TODO
in the parser.
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng,master.tryserver.v8:v8_linux64_msan_rel,v8_linux64_tsan_rel,v8_linux_arm64_dbg,v8_linux_gc_stress_dbg,v8_linux_noi18n_rel_ng,v8_linux_nosnap_rel
Change-Id: I693a858a638753f8c1091f2f9086710f628b40dd
Reviewed-on: https://chromium-review.googlesource.com/553677
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46634}
This reverts commit 5648aad553.
Reason for revert: Compile error on mips:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/10732
Original change's description:
> [wasm] Don't store global handles in the interpreter
>
> Storing global handles in the interpreter is dangerous, because the
> global handles are strong roots into the heap. The interpreter itself is
> referenced from the heap via a Managed. Hence the interpreter keeps the
> instance alive, while the instance keeps the Managed alive. So the GC
> will never collect them.
>
> This CL refactors this to only store the handle to the instance object
> while executing in the interpreter, and clearing it when returning.
> It also removes the cache of import wrappers, as it should not be
> performance critical, but keeps lots of objects alive. If it turns out
> to be performance critical, we will have to reintroduce such a cache
> stored in the WasmDebugInfo object.
>
> R=titzer@chromium.org
> CC=ahaas@chromium.org
>
> Bug: chromium:610330
> Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
> Reviewed-on: https://chromium-review.googlesource.com/567058
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46629}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: Ifadfb885f937f37bb3eab4732a97f20ff40c2583
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:610330
Reviewed-on: https://chromium-review.googlesource.com/569962
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46630}
Storing global handles in the interpreter is dangerous, because the
global handles are strong roots into the heap. The interpreter itself is
referenced from the heap via a Managed. Hence the interpreter keeps the
instance alive, while the instance keeps the Managed alive. So the GC
will never collect them.
This CL refactors this to only store the handle to the instance object
while executing in the interpreter, and clearing it when returning.
It also removes the cache of import wrappers, as it should not be
performance critical, but keeps lots of objects alive. If it turns out
to be performance critical, we will have to reintroduce such a cache
stored in the WasmDebugInfo object.
R=titzer@chromium.orgCC=ahaas@chromium.org
Bug: chromium:610330
Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb
Reviewed-on: https://chromium-review.googlesource.com/567058
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46629}
When disassembling some instructions we would print `r12`, which can be
confusing when the rest of the disassembly consistently uses `ip`.
Bug:
Change-Id: Id4cfc5805ef102a0845cdaaa8390e618ee981b19
Reviewed-on: https://chromium-review.googlesource.com/570038
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#46628}
There is just one version now, called IsPowerOfTwo. It accepts any
integral type.
There is one slight semantical change: Called with kMinInt, it
previously returned true, because the argument was implicitly casted to
an unsigned. It's now (correctly) returning false, so I had to add
special handlings of kMinInt in machine-operator-reducer before calling
IsPowerOfTwo on that value.
R=mlippautz@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,ishell@chromium.org,yangguo@chromium.org
Change-Id: Idc112a89034cdc8c03365b778b33b1c29fefb38d
Reviewed-on: https://chromium-review.googlesource.com/568140
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46627}
This CL changes the USE macro to accept more than one parameter.
This is particularly interesting for calling a method on each type in a
parameter pack, as in:
template<typename... T>
void foo(T&&... ts) {
USE(do_something(ts)...);
}
Drive-by fix: Allow to pass arbitrary types to USE, including
references. This might prevent a copy for pass-by-value.
R=ishell@chromium.org, tebbi@chromium.org
Also-by: tebbi@chromium.org
Change-Id: I544e83bb996aaa638e7512295973dd3e742254bc
Reviewed-on: https://chromium-review.googlesource.com/567507
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46626}
It's ok that the instance of the called code object is different from
the caller instance. This happens if one instance calls an exported
function of another instance.
R=ahaas@chromium.org
Bug: chromium:739768
Change-Id: I6afa8332a9b33fe32e9332cdca573053f058421d
Reviewed-on: https://chromium-review.googlesource.com/568494
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46624}
The shortcuts ensure that field type generalization is properly
propagated in the transition graph.
Bug: chromium:738763
Change-Id: Id701a6f95ed6ea093c707fbe0bac228f1f856e9f
Reviewed-on: https://chromium-review.googlesource.com/567992
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46622}
This correctly types values loaded via {LoadElement} nodes from arrays
of HOLEY_DOUBLE_ELEMENTS elements kind as {Type::NumberOrHole}. Even
though "the hole" is still encoded as a tagged NaN, the type system
still needs to consider it as a potential hole value.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-736575
BUG=chromium:736575
Change-Id: Ib869284900a4affb2ddaa1d2a96df9443dba6921
Reviewed-on: https://chromium-review.googlesource.com/567180
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46620}
Previously we enforced that all lengths for ArrayLike objects must
be within Smi range, but all negative numbers should actually be first
converted to +0.
Bug: chromium:740372
Change-Id: If50de9ce0eeb7cb09e14b8e8803f434350d00508
Reviewed-on: https://chromium-review.googlesource.com/566867
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46615}
Insertion into a collection changes the map because of the addition of
the hash value property. Check the root map, not the current map.
Fixes: https://github.com/nodejs/node/issues/14139
Change-Id: Iabcea5337323b9b6deffa1a06892c1cb749f2065
Reviewed-on: https://chromium-review.googlesource.com/566833
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46614}
Didn't seem to help and caused a couple of regressions.
BUG=v8:6243,chromium:740124
Change-Id: I72887ba245a524211dbf181c77d0cdc6d917d090
Reviewed-on: https://chromium-review.googlesource.com/568480
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46608}
When we abort preparsing, we have to reset the Scope state, to ensure
re-parsing will leave us in the proper Zone. Resetting of rare_data_
was missing, causing this to fail in some cases.
Bug: chromium:740803
Change-Id: I7ce70f9c4670eaf1b76745ae8231eb95625b0f4b
Reviewed-on: https://chromium-review.googlesource.com/568784
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46607}
By creating the boilerplate only on the second instantiation we cannot
propagate back the elements transitions early enough. The resulting literals
would change the initial ElementsKind one step too late and already pollute
ICs that went to monomorphic state.
- Disable lazy AllocationSites for literals containing arrays
- Introduce new ComplexLiteral class to share code between ObjectLiteral
and ArrayLiteral
- RegexpLiteral now no longer needs a depth_ field
Bug: v8:6517, v8:6519, v8:6211
Change-Id: Ia88d1878954e8895c3d00a7dda8d71e95bba005c
Reviewed-on: https://chromium-review.googlesource.com/563305
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46603}
This is a reland of f720d024dc
Original change's description:
> [mjsunit] Improve mjsunit stracktrace readability
>
> Format the function name and file-position into proper columns to easily spot
> where the test code ends and the mjsunit framework code starts.
>
> BEFORE:
> Stack: Error
> at new MjsUnitAssertionError (test/mjsunit/mjsunit.js:36:18)
> at failWithMessage (test/mjsunit/mjsunit.js:310:11)
> at fail (test/mjsunit/mjsunit.js:327:12)
> at assertEquals (test/mjsunit/mjsunit.js:398:7)
> at closure (test/mjsunit/regress/regress-4121.js:20:7)
> at literals_sharing_test (test/mjsunit/regress/regress-4121.js:27:3)
> at test (test/mjsunit/regress/regress-4121.js:37:5)
> at eval (eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6), <anonymous>:1:1)
> at test/mjsunit/regress/regress-4121.js:49:6
> at Array.forEach.call (test/mjsunit/regress/regress-4121.js:50:7)
> throw new MjsUnitAssertionError(message);
>
> AFTER:
> Stack: MjsUnitAssertionError
> at assertEquals test/mjsunit/mjsunit.js 398:7
> at closure test/mjsunit/regress/regress-4121.js 20:7
> at literals_sharing_test test/mjsunit/regress/regress-4121.js 27:3
> at test test/mjsunit/regress/regress-4121.js 37:5
> at eval eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6)
> at test/mjsunit/regress/regress-4121.js 49:6
> at Array.forEach.call test/mjsunit/regress/regress-4121.js 50:7
> throw new MjsUnitAssertionError(message);
>
>
> Change-Id: Iad3460a648e26effb43c00426ab043743ee6a138
> Reviewed-on: https://chromium-review.googlesource.com/563627
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46589}
Change-Id: I44bf07f7be4114369315605542cafd17345b4397
Reviewed-on: https://chromium-review.googlesource.com/567063
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46602}
JSFunction::SetName can fail if it tries to create a string with
length > String::kMaxLength (either by prepending "set "/"get " or
by surrounding a Symbol descriptor with "["/"]").
This patch propagates that exception to the surrounding code rather
than CHECK-failing.
Bug: chromium:740398
Change-Id: I394943af481f3147387dd82ec5862d7071d57827
Reviewed-on: https://chromium-review.googlesource.com/566092
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46601}
This makes it possible for automated tests to distinguish between CHECK
failures and DCHECK failures, the latter of which will continue to run
in release builds after the assertion failure point.
Change-Id: Ie26978c0342d401a8c85f3261749739195087579
Reviewed-on: https://chromium-review.googlesource.com/565515
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46596}
This reverts commit f720d024dc.
Reason for revert: Bot failure at
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20custom%20snapshot%20-%20debug/builds/15690
Original change's description:
> [mjsunit] Improve mjsunit stracktrace readability
>
> Format the function name and file-position into proper columns to easily spot
> where the test code ends and the mjsunit framework code starts.
>
> BEFORE:
> Stack: Error
> at new MjsUnitAssertionError (test/mjsunit/mjsunit.js:36:18)
> at failWithMessage (test/mjsunit/mjsunit.js:310:11)
> at fail (test/mjsunit/mjsunit.js:327:12)
> at assertEquals (test/mjsunit/mjsunit.js:398:7)
> at closure (test/mjsunit/regress/regress-4121.js:20:7)
> at literals_sharing_test (test/mjsunit/regress/regress-4121.js:27:3)
> at test (test/mjsunit/regress/regress-4121.js:37:5)
> at eval (eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6), <anonymous>:1:1)
> at test/mjsunit/regress/regress-4121.js:49:6
> at Array.forEach.call (test/mjsunit/regress/regress-4121.js:50:7)
> throw new MjsUnitAssertionError(message);
>
> AFTER:
> Stack: MjsUnitAssertionError
> at assertEquals test/mjsunit/mjsunit.js 398:7
> at closure test/mjsunit/regress/regress-4121.js 20:7
> at literals_sharing_test test/mjsunit/regress/regress-4121.js 27:3
> at test test/mjsunit/regress/regress-4121.js 37:5
> at eval eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6)
> at test/mjsunit/regress/regress-4121.js 49:6
> at Array.forEach.call test/mjsunit/regress/regress-4121.js 50:7
> throw new MjsUnitAssertionError(message);
>
>
> Change-Id: Iad3460a648e26effb43c00426ab043743ee6a138
> Reviewed-on: https://chromium-review.googlesource.com/563627
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46589}
TBR=machenbach@chromium.org,cbruni@chromium.org,ishell@chromium.org
Change-Id: I631cec7f318637ce2f60500e2bf0ab7fe1f6d09e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/567062
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46592}
This CL moves collected source range information out of AST nodes
and into a side table stored on ParseInfo. The side table is only
created if block coverage is enabled, so there's almost no memory
overhead in the standard case.
Change-Id: I41871b8425ebbc6217d82d3ad26b5fc9e5d68ecb
Reviewed-on: https://chromium-review.googlesource.com/566808
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46590}
Format the function name and file-position into proper columns to easily spot
where the test code ends and the mjsunit framework code starts.
BEFORE:
Stack: Error
at new MjsUnitAssertionError (test/mjsunit/mjsunit.js:36:18)
at failWithMessage (test/mjsunit/mjsunit.js:310:11)
at fail (test/mjsunit/mjsunit.js:327:12)
at assertEquals (test/mjsunit/mjsunit.js:398:7)
at closure (test/mjsunit/regress/regress-4121.js:20:7)
at literals_sharing_test (test/mjsunit/regress/regress-4121.js:27:3)
at test (test/mjsunit/regress/regress-4121.js:37:5)
at eval (eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6), <anonymous>:1:1)
at test/mjsunit/regress/regress-4121.js:49:6
at Array.forEach.call (test/mjsunit/regress/regress-4121.js:50:7)
throw new MjsUnitAssertionError(message);
AFTER:
Stack: MjsUnitAssertionError
at assertEquals test/mjsunit/mjsunit.js 398:7
at closure test/mjsunit/regress/regress-4121.js 20:7
at literals_sharing_test test/mjsunit/regress/regress-4121.js 27:3
at test test/mjsunit/regress/regress-4121.js 37:5
at eval eval at <anonymous> (test/mjsunit/regress/regress-4121.js:49:6)
at test/mjsunit/regress/regress-4121.js 49:6
at Array.forEach.call test/mjsunit/regress/regress-4121.js 50:7
throw new MjsUnitAssertionError(message);
Change-Id: Iad3460a648e26effb43c00426ab043743ee6a138
Reviewed-on: https://chromium-review.googlesource.com/563627
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46589}
This patch teaches the parser that async functions are not valid
destructuring targets so that it can cleanly exit with a SyntaxError.
Previously, async functions used in the wrong position would lead
to a check failure.
Bug: chromium:740366
Change-Id: Ie5b0cf50326c3f96174c6b29d0ccedb5da4f75a2
Reviewed-on: https://chromium-review.googlesource.com/567002
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46587}
This makes sure the inline allocation of generator objects only shrinks
initial maps when slack tracking is actually in progress. Shrinking all
unused properties unconditionally is bogus because instances using them
might have become unreachable and collected by the GC.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-741078
BUG=chromium:741078
Change-Id: Iaf2f08a4fa82c820a945bf012d24c760a6b4f514
Reviewed-on: https://chromium-review.googlesource.com/567982
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46585}
In certain timezones, being at noon UTC doesn't guarantee that
you'll be the same day in local time. This patch fixes that
false assumption. Thanks to Holmes He for reporting the issue.
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I7432c0eb1e13fdf11c665e59dabaebeb79bff8c8
Reviewed-on: https://chromium-review.googlesource.com/568021
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46584}
This introduces 2^16 as an upper limit for the allowed value range of a
table switch on all architectures. It also fixes several overflows in
the table size calculation.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-736633
BUG=chromium:736633
Change-Id: I931bd226c99eb8a1ae1770c159fc314ff650bf57
Reviewed-on: https://chromium-review.googlesource.com/566829
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46575}
Previously (since f0e95769), this toLowerCase fast-path assumed
it would only see one-byte flat contents. Unfortunately, it's
possible to have a one-byte sliced string that has a two-byte parent.
This CL ensures that String.p.toLowerCase handles such cases
correctly.
BUG=chromium:736451
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iae056b3db5535bb5665439a5cc8282a51571a548
Reviewed-on: https://chromium-review.googlesource.com/565559
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46574}
This patch changes the backing store of slow properties to be a
new instance type called PropertyArray.
Currently the only difference between this and a FixedArray is
the map. A future patch will change the length property to store
the hash code.
Bug: v8:5717, v8:6404
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iaebc98f42e6d93c1392772e6f837787beb64afec
Reviewed-on: https://chromium-review.googlesource.com/539028
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46569}
Otherwise user code can produce an exception and we will crash.
R=jakob@chromium.org
Bug: chromium:736302
Change-Id: I078150909b0348a63e8c375b508e34fc4751b4ab
Reviewed-on: https://chromium-review.googlesource.com/565628
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46566}
After compiling a function, check that validation produces the same
success/error result.
R=ahaas@chromium.org
Change-Id: I617881e125dccff485f5572557b19709de488d55
Reviewed-on: https://chromium-review.googlesource.com/565722
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46561}
This fixes the lowering of Reflect.getPrototypeOf and friends to not
perform a [[ToObject]] coercion, but bailout instead. We ensure to
exclude primitive values from the lowering. This makes the lowering
uniform between "Reflect.getPrototypeOf" and "Object.getPrototypeOf".
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-740116
BUG=chromium:740116
Change-Id: If986ee2a3ae4e8f1fd227bdeb4668f523b0dea84
Reviewed-on: https://chromium-review.googlesource.com/565295
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46556}
Each reducer now has a virtual reducer_name function, returning its name
(the name of the class containing this reducer). This gets displayed when
using the --trace_turbo_reduction flag. Also when using this flags more
messages are displayed.
Actually when a node is replaced in-place (which is called an update
of the node), other reducers can still update it right after the
in-place replacement. When a node is really replaced (not in-place),
then we stop trying to apply reducers to it before we propagate the
reduction through the relevant nodes.
Before a message got printed only for the last reduction it went
through. So in case a node was reduced in-place several times
in a row, only the last update was printed, or none at all if after
being reduced in-place it got reduced by being replaced by another
node: only the non-in-place replacement was showed.
Now each time an in-place reduction is applied to a node, a message
gets printed.
Bug:
Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa
Reviewed-on: https://chromium-review.googlesource.com/563365
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Alexandre Talon <alexandret@google.com>
Cr-Commit-Position: refs/heads/master@{#46552}
Switch statements generate a counter for each clause plus a continuation
counter.
Bug: v8:6000
Change-Id: Ic55a7efda54de1152bd5283d753119aa2764afbd
Reviewed-on: https://chromium-review.googlesource.com/558249
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46550}
- Implement js-api changes for WebAssembly.Memory to accept a shared parameter
- Update allocation to use SharedArrayBuffers
BUG=v8:6532
R=binji@chromium.org, bradnelson@chromium.org
Change-Id: I021491217568751b06fbd7b4b08b1dd88910e21d
Reviewed-on: https://chromium-review.googlesource.com/564058
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46543}
This is a reland of 5b44ba0e34
Original change's description:
> (Reland) [parser] moved load property position after dot
>
> Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
> It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
>
> R=jgruber@chromium.org
> TBR=marja@chromium.org
>
> Bug: v8:6425
> Change-Id: I05c21ca5e018da9c432c6bc963c7a96799336d1c
> Reviewed-on: https://chromium-review.googlesource.com/562879
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46484}
TBR=marja@chromium.org,jgruber@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Bug: v8:6425
Change-Id: I5eba5fe43ad31c5c781ffcc8c604cd9c98baa57e
Reviewed-on: https://chromium-review.googlesource.com/565907
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46542}
Adds missing opcodes for exception handling for the function body decoder.
Also adds error messages if the exception handling construct is not yet
functional.
Note that the previous prototype for catch and throw have been marked
as not yet functional. This was done because it doesn't model
exceptions the way the proposal suggests. Rather, they implement a
hard-coded (c++ model) of exceptions.
Bug: v8:6577
Change-Id: Ife170b9f0cb2be91b11082e43c4795ce81a427dc
Reviewed-on: https://chromium-review.googlesource.com/564138
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46540}
Modifies V8 to be able to parse the exception section (defining
exception types), when the experimental_wasm_eh flag is true.
Bug: v8:6577
Change-Id: I5d8b3fddaf5b0dec6b14ddd0992f9fb883e8dc90
Reviewed-on: https://chromium-review.googlesource.com/561757
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46539}
This improves the general Array constructor call performance (w/o
usable AllocationSite feedback) in TurboFan by ~2x, i.e. for example
invoking the Array constructor like this
var a = Array.call(undefined, n);
instead of
var a = Array(n);
such that the CallIC doesn't know that it's eventually calling the
Array constructor.
It also thus changes the single argument Array constructor to always
return holey arrays. Previously the single argument case for the Array
constructor was somehow trying to dynamically detect 0 and in that case
returned a packed array instead of a holey one. That adds quite a lot
of churn, and doesn't seem to be very useful, especially since this
might lead to unnecessary feedback pollution later.
R=mvstanton@chromium.org
Bug: v8:2229, v8:5269, v8:6399
Change-Id: I3d7cb9bd975ec0e491e3cdbcf1230185cfd1e3de
Reviewed-on: https://chromium-review.googlesource.com/565721
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46538}
It's already skipped (for slowness) in debug, asan, and msan builds.
TBR=machenbach@chromium.org
Change-Id: I1d7cb38d88e621f6d14344426bc5f931b1d6ffcd
Reviewed-on: https://chromium-review.googlesource.com/565741
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46537}
In https://chromium-review.googlesource.com/c/472247/, I avoided
running DesugarLexicalBindingsInForStatement() if there were no lexical
loop variables, the function was not resumable, and the variables are
not captured by eval or a function declaration.
I think it's now possible to limit this further, and only do the more
extensive desugaring if there's a function declaration / eval() call
in the loop body. `yield` and `await` are not an issue as those loop
variables are written to the register file and not lost.
This change just removes the `is_resumable()` condition. If it passes
tests, I think it's safe.
BUG=v8:4762, v8:5460, v8:6579
Change-Id: I92d0308ad9401c1338411bc9ae9021f978803d3a
Reviewed-on: https://chromium-review.googlesource.com/563587
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46536}
This will allow for passing more than one variable. This is
particularly interesting for calling a method on each type in a
parameter pack, as in:
template<typename... T>
void foo(T&&... ts) {
USE(do_something(ts)...);
}
Drive-by fix: Allow to pass arbitrary types to USE, including
references. This might prevent a copy for pass-by-value.
R=ishell@chromium.org
Change-Id: I8f894d730bbcd195ed83705f98771994b4bc906f
Reviewed-on: https://chromium-review.googlesource.com/565561
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46527}
This adds a convenience method for the common Smi to int conversion
pattern.
Bug:
Change-Id: I7d7b171c36cfec5f6d10c60f1d9c3e06e3aed0fa
Reviewed-on: https://chromium-review.googlesource.com/563205
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46516}
An invalid I32V value as index could be used to get a valid
WasmFunction.
R=clemensh@chromium.org
Bug: chromium:735887
Change-Id: I5fbfa01fc3300d86a4a2ba9bcbb86fc02f231ef9
Reviewed-on: https://chromium-review.googlesource.com/561536
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46504}
There are other things to export beside functions. Thus, also print the
export kind when printing an error for duplicate export names.
R=titzer@chromium.org
Change-Id: I7477040dda274a16cfd776d7ac8db6e50a197b97
Reviewed-on: https://chromium-review.googlesource.com/564940
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46503}
... according to the spec ES#sec-%throwtypeerror%
Bug: v8:4034
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ia4f2d228397edf55447fe3e71402c8fc4589369a
Reviewed-on: https://chromium-review.googlesource.com/563214
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46498}
This is the next step towards faster Map and Set iteration. It
introduces the appropriate instance types for Map and Set
iterators (following the pattern for Array iterators) and migrates
the following builtins to the CodeStubAssembler:
- Set.prototype.entries
- Set.prototype.values
- Map.prototype.entries
- Map.prototype.keys
- Map.prototype.values
- %SetIteratorPrototype%.next
- %MapIteratorPrototype%.next
This already provides a significant performance boost for regular
for-of iteration of Sets and Maps, by a factor of 5-10 depending
on the input. The final step will be to inline some fast-paths
into TurboFan.
Drive-by-fix: Remove obsolete %IsJSSetIterator and %IsJSMapIterator
intrinsics and runtime functions.
TBR=jgruber@chromium.org
Bug: v8:6344, v8:6571, chromium:740122
Change-Id: I3ab0ee49e2afe8d4295707a5ecbd51adda621918
Reviewed-on: https://chromium-review.googlesource.com/563626
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46497}
This reverts commit 5b44ba0e34.
Reason for revert: Layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16841
Original change's description:
> (Reland) [parser] moved load property position after dot
>
> Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
> It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
>
> R=jgruber@chromium.org
> TBR=marja@chromium.org
>
> Bug: v8:6425
> Change-Id: I05c21ca5e018da9c432c6bc963c7a96799336d1c
> Reviewed-on: https://chromium-review.googlesource.com/562879
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46484}
TBR=kozyatinskiy@chromium.org,jgruber@chromium.org
Change-Id: If9d5fa5f46ed10a407559e9cf10d2a6a54dbe163
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6425
Reviewed-on: https://chromium-review.googlesource.com/564418
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46491}
BUG=v8:6231
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I326ace8ee27e5347d26bae11b8061f4fe524db53
Reviewed-on: https://chromium-review.googlesource.com/562744
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46488}
... but use proper map for functions with readonly prototype from the start.
Bug: v8:6459
Change-Id: I432d4969822e7cc4c2ba83e103f550d1c4f2e234
Reviewed-on: https://chromium-review.googlesource.com/563199
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46487}
Currently LdaNamedProperty bytecode for expressions like a.b has position before dot. This CL moves this location after dot.
It's important for later removing of Nop bytecodes in expressions like a.b() where a is local variable, property call and property load should have the same position.
R=jgruber@chromium.orgTBR=marja@chromium.org
Bug: v8:6425
Change-Id: I05c21ca5e018da9c432c6bc963c7a96799336d1c
Reviewed-on: https://chromium-review.googlesource.com/562879
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46484}
This CL refactors the WasmMemoryObject and WasmInstanceObject classes to
use WeakFixedArray instead of using a doubly-linked list of instances. This
simplifies the lifetime management of instances by not requiring them to
be unlinked from this list upon GC. It also simplifies the iteration over
the instances using a given WasmMemoryObject.
Note that, contrary to my naive assumption at the outset, it is still necessary for the InstanceFinalizer (called upon a WasmInstanceObject death) to unlink itself from a WasmMemoryObject's instances list, due to finalizer ordering.
R=deepti@chromium.org, mlippautz@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2972803002
Cr-Commit-Position: refs/heads/master@{#46482}
This adds support for exception control flow by adding a counter behind throw
statements (never incremented), as well as a counter for catch and finally
blocks.
Bug: v8:6000
Change-Id: I3959772c889b543ab5e186ad7cd710e55a8aec23
Reviewed-on: https://chromium-review.googlesource.com/558993
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46476}
This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).
In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.
BUG=v8:6547
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2964943002
Cr-Commit-Position: refs/heads/master@{#46475}
This CL changes for floats what https://chromium-review.googlesource.com/c/558964/
changed for doubles.
Original message:
On x86, signalling NaNs get converted to quiet NaNs when they get push
on the stack and popped again. This happens in the code generation for
arm, specifically for the vmov instruction with the immediate parameter.
This CL replaces the vmov function in assembler-arm to take the
immediate as a uint64_t instead of a double, to guarantee that the bit
pattern does not change even if the parameter is a signalling NaN.
New in this CL:
Although src/double.h existed already, src/float.h did not exist yet.
I created the file in this CL, and moved the classes Float32 and
Float64 there, which already existed in src/deoptimizer.h.
R=titzer@chromium.org, martyn.capewell@arm.com, v8-arm-ports@googlegroups.com
BUG=v8:6564
Change-Id: I6a3f1f154af9c8cd4bb8e7e856235d3eee5e9edd
Reviewed-on: https://chromium-review.googlesource.com/561009
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46473}
This CL contains new created tests for instructions INS and EXT.
TEST=cctest/test-assembler-mips[64]/Ins,
cctest/test-assembler-mips[64]/Ext
BUG=
Change-Id: Ie62037ee425a5cba3700c5025608fdada144add5
Reviewed-on: https://chromium-review.googlesource.com/561319
Commit-Queue: Miran Karić <Miran.Karic@imgtec.com>
Reviewed-by: Miran Karić <Miran.Karic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46468}
Blink needs %ErrorPrototype% in order to properly set up the inheritance
chain from DOMException, as specified in WebIDL:
https://heycam.github.io/webidl/#es-DOMException-specialness
This patch is similar to commit 5ec1cddcd ("Expose %IteratorPrototype% as an
intrinsic in the public API"), with the difference that there was no entry
for %ErrorPrototype% in any of the mappings in contexts.h.
Bug: chromium:556950, chromium:737497
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iadc5b2b844f29f6c9640b6a89769d233931366e9
Reviewed-on: https://chromium-review.googlesource.com/559058
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#46464}
This adds a new binary block coverage mode (in addition to the existing count
block coverage), as well as a few transformation passes to reduce the number of
uselessly reported ranges.
Bug: v8:6000
Change-Id: I4fb234ca015990d00aa2f1dccb87f76ba4748994
Reviewed-on: https://chromium-review.googlesource.com/552642
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46463}
Adds constant folding for the StringConcat bytecode to
NativeContextSpecialization. Can reduce operator to either a fully folded
constant string, or a JSAdd or a StringConcat with a reduced number of
operators.
BUG=v8:6243, chromium:738312
Change-Id: I6b2be6a3d95230a23f3c7390a4f7be5181c49a2a
Reviewed-on: https://chromium-review.googlesource.com/559146
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46461}
If a thin string can be dereferenced for StringConcat we still need to check
whether the dereferenced string is a sequential string itself (it could be
an external string).
BUG=v8:6243
Change-Id: I146541512525726f092580512c0b5f02d33685a7
Reviewed-on: https://chromium-review.googlesource.com/558994
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46459}
Print the object that is being destructured and update the error
message.
Previously,
d8> var [a] = {}
(d8):1: TypeError: [Symbol.iterator] is not a function
Now,
d8> var [a] = {}
(d8):1: TypeError: {} is not iterable
Bug: v8:6513, v8:5532
Change-Id: I5cbfe7c7e20632bce1a48bd38a1b0c98d0ff0660
Reviewed-on: https://chromium-review.googlesource.com/557370
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46457}
The ')'-in-parameter checking is not necessary for
CompileFunctionInContext. The arguments array is expected to be an
array of identifiers, not an array of arbitrary strings that get
concatenated.
Furthermore, there's no reason to have the .toString() representation
look like it came from CreateDynamicFunction(), and in fact inserting
line breaks makes it more complicated to map line and column numbers
correctly.
Overall, the --harmony-function-tostring behavior only makes
CompileFunctionInContext worse, so this CL removes it.
R=littledan@chromium.org, adamk@chromium.org, caitp@igalia.com
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Bug: v8:4958
Change-Id: Ifbc8a83216ca6a6979da1199972aa65f4bee36c3
Reviewed-on: https://chromium-review.googlesource.com/558220
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Josh Wolfe <jwolfe@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46456}
Tsan figured out that I called compilation_units_.empty() outside a
lock.
Original message:
This CL adds a new function {InitializeCompilationUnit} to initialize
a single compilation unit and not just all compilation units at once.
This is necessary for streaming compilation eventually. This also
required some refactoring on how the working queue for compilation units
works. Previously the synchronization was done with an atomic counter,
now it is done with a lock. Note that the code to finish compilation
of a module still only works if the working queue gets only empty when
all work is done. I plan to change this in a different CL.
Since the code would not be tested without streaming compilation, I added
an experimental flag and a test to test the new code.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: Ia83560d1c70f0802271a88c514e0d1cb0458f6c4
Reviewed-on: https://chromium-review.googlesource.com/561458
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46454}
In the original CL I moved an error check backwards, unfortunately
behind a vector lookup which should not happen when there is an error.
Now I also move the vector lookup backwards.
Original message:
We stored the size of a function body before we check that
these values are valid. This caused a failing DCHECK in the constructor
of WireBytesRef which checked for integer overflows. With this CL we
check the size of the function body before we create the WireBytesRef.
R=clemensh@chromium.org
Bug: chromium:738097
Change-Id: Ie65b3cfcbcd6bdb3f04b0760673d9c7b7a0d1057
Reviewed-on: https://chromium-review.googlesource.com/561519
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46453}
This CL adds a few transformations that clean up the set of reported
source ranges. Duplicates, empty, and uncovered ranges are removed, and
nested/consecutive ranges are merged if possible.
BUG=v8:6000
Change-Id: I421ee35ce8292cfe84c1eea4f653762cea5d909d
Reviewed-on: https://chromium-review.googlesource.com/558411
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46450}
Replaces the old PromotionQueue that was kept at the end of to space.
This change allows a future implementation to use
(a) a thread-local promotion list and
(b) enables work stealing for concurrent scenarios.
Bug: chromium:738865
Change-Id: I4c983a36e69ad4a9462eb9a59f586a85e51acbde
Reviewed-on: https://chromium-review.googlesource.com/561141
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46446}
This reverts commit 6c8aed76ff.
Reason for revert: Breaks some debug bots:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug/builds/16754https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/17654
Original change's description:
> [wasm] Check the size of a function body before storing it
>
> We stored the size of a function body before we check that
> these values are valid. This caused a failing DCHECK in the constructor
> of WireBytesRef which checked for integer overflows. With this CL we
> check the size of the function body before we create the WireBytesRef.
>
> R=clemensh@chromium.org
>
> Bug: chromium:738097
> Change-Id: I18f8b628c1499aae9c8e9340ea73c87f19e6f1d7
> Reviewed-on: https://chromium-review.googlesource.com/561000
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46442}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: Ifd533c0dee369c746bc97fea13275ebc09ed5eff
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:738097
Reviewed-on: https://chromium-review.googlesource.com/561517
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46445}
We stored the size of a function body before we check that
these values are valid. This caused a failing DCHECK in the constructor
of WireBytesRef which checked for integer overflows. With this CL we
check the size of the function body before we create the WireBytesRef.
R=clemensh@chromium.org
Bug: chromium:738097
Change-Id: I18f8b628c1499aae9c8e9340ea73c87f19e6f1d7
Reviewed-on: https://chromium-review.googlesource.com/561000
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46442}
TruncateDoubleToI generated a 32-bit result but did not clear the upper
32 bits. This violated the invariant that the upper 32 bits should be
cleared when the result is 32 bits. This change fixes the bug mentioned
below. Clearing the upper 32 bits is also done on x64.
R=v8-arm-ports@googlegroups.com, titzer@chromium.org, martyn.capewell@arm.com
Bug: chromium:738952
Change-Id: I7e23e03fbed380ff08803db41fbae6382957ba08
Reviewed-on: https://chromium-review.googlesource.com/559671
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46440}
Remove all IsHeapObject/IsSmi checks from assembler and also from
the macro-assembler functions that Turbofan code generation uses.
Note for porters: In case it's unclear which macro-assembler
functions need to be modified, it may be best to wait until I
split MacroAssembler in a followup-CL, which will make that clear.
Bug: v8:6048
Change-Id: Ife0735cc6f48713c9ec493faf2dac5e553d1c06b
Reviewed-on: https://chromium-review.googlesource.com/561015
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46436}
Introduce a stripped down version of UseScratchRegisterScope for ARM and use it
inside the assembler and macro-assembler. At the exception of the Call
instructions, we now use this scope instead of using the ip register
directly. This is inspired from how the ARM64 backend works.
In general, the benefit of doing this is we can catch cases where ip is being
used both by the caller and by the assembler. But more specifically, TurboFan
reserves r9 as an extra scratch register because ip can already be used by the
assembler. With this utility, we can isolate the cases in the code generator
which need an extra register and potentially fix them, allowing us to give r9
back to the register allocator.
This patch uncovered places in the assembler where we were using ip
unconditionally when we could have re-used the destination register instead.
Bug: v8:6553
Change-Id: Ib7134e3ed64dd1f90baf209ae831ed8f644cac78
Reviewed-on: https://chromium-review.googlesource.com/544956
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46425}
On x86, signalling NaNs get converted to quiet NaNs when they get push
on the stack and popped again. This happens in the code generation for
arm, specifically for the vmov instruction with the immediate parameter.
This CL replaces the vmov function in assembler-arm to take the
immediate as a uint64_t instead of a double, to guarantee that the bit
pattern does not change even if the parameter is a signalling NaN.
BUG=v8:6564
Change-Id: I062559f9a7ba8b0f560628e5c39621ca578c3e7d
Reviewed-on: https://chromium-review.googlesource.com/558964
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#46418}
If the input array is small, then the cost of a trip to the
runtime to transition the ElementsKind is too expensive.
Bug:
Change-Id: Ib04f8567674a6f1f66f4c7263eba5fb4c58987aa
Reviewed-on: https://chromium-review.googlesource.com/544866
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46417}
Instead of counting profiler ticks on the shared function info (which is
shared between native contexts), count them on the feedback vector
(which is not). This allows us to continue pushing optimization
decisions off the SFI, onto the feedback vector.
Note that a side-effect of this is that ICs don't have to walk the stack
to reset profiler ticks, as they can access the feedback vector directly
from their feedback nexus.
Change-Id: I232ae9e759fca75cd89d393148a4ff42caa2646f
Reviewed-on: https://chromium-review.googlesource.com/544888
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46411}
To be used with tuples of heap objects and sizes.
Bug: chromium:738865
Change-Id: I29d9cf98bb2097cc8e1616aaf19a251507ffbd9e
Reviewed-on: https://chromium-review.googlesource.com/559050
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46407}
In case of LAP(lazy accessor pair), the function's creation context
must be equal to the accessor holder's creation context, so this CL
changes the current context to the accessor holder's creation context.
BUG=v8:6156
Review-Url: https://codereview.chromium.org/2770003002
Cr-Commit-Position: refs/heads/master@{#46406}
This is a preliminary step before we stop swapping maps in the bootstrapper
(strict/sloppy map with writable prototype <-> readonly prototype).
Bug: v8:6459
Change-Id: I120550c10e98a234e283d79a8d408096601c92af
Reviewed-on: https://chromium-review.googlesource.com/558879
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46403}
Instead of having the "next step" state machine logic in the compiler
dispatcher, move it to the compiler dispatcher job. This is a
prerequisite to having more generic jobs with slightly different state
sets, such as an optimizing compile job.
Bug: v8:6537
Change-Id: Ib7319222f26dbc0e2afc95573b06d813825afde3
Reviewed-on: https://chromium-review.googlesource.com/554751
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46396}
Every, Some, Reduce, ReduceRight. Added a test that should improve
when TurboFan inlines these builtins. Updated Map and Filter tests
to include a TurboFan inline test.
Bug: v8:2229
Change-Id: Ie84d414fdcccea23c734caca55a3344f9442547f
Reviewed-on: https://chromium-review.googlesource.com/558935
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46395}
On Loongson 3A, MADD/MSUB instructions are actually fused MADD/MSUB and
they can cause failure in some of the tests. Since this optimization is
rarely used, and not used at all on MIPS64R6, MADD/MSUB instructions
are removed from the source base.
TEST=
BUG=
Change-Id: Ifbb5508a62731bb061f332864ffd1e210e97f963
Reviewed-on: https://chromium-review.googlesource.com/558066
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46387}
When providing scope information (containing the value of local
variables of live stack frames), decode the local variable names of all
functions in a wasm module and store this in the WasmDebugInfo
structure.
Use these names to actually name the reported locals, instead of using
the default names "param#<d>" and "local#<d>". These names are only used
as fallbacks for locals which were not assigned a name.
R=titzer@chromium.org,kozyatinskiy@chromium.org
BUG=v8:6245
Change-Id: Ibf7d30e392248ef5590177cd8b6329239b45e018
Reviewed-on: https://chromium-review.googlesource.com/548495
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46379}
Instructions ins and ext didn't work properly when size = 32 because of
incorrect mask initialization, this CL fixes this. A test for Ins is
also added.
BUG=
Change-Id: I95cc8e13aaa2341b34ae59dae1eefb64c551b8b4
Reviewed-on: https://chromium-review.googlesource.com/558872
Commit-Queue: Miran Karić <Miran.Karic@imgtec.com>
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#46378}
The jsapi-harness test runs the JS-API spec tests of WebAssembly, which
get fetched from github when 'gclient sync' is executed. Without
'gclient sync' the harness may executed a version of the tests which is
older than required by the harness. In this CL I add a suggestion to
the test to run 'gclient sync' which is shown when the test is failing.
R=marja@chromium.org
Change-Id: I36d03bebc4d6cc554eefd4eb376c3d309b7ee5b9
Reviewed-on: https://chromium-review.googlesource.com/558419
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46375}
This sometimes caused problems with bots (for node too) because the
allocation could fail.
Bug: v8:6452
Change-Id: I346a9117eba8b6ed41566efeceaf7fb190784d76
Reviewed-on: https://chromium-review.googlesource.com/558075
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46373}
These were originally written as part of
https://chromium-review.googlesource.com/c/550396/. I've separated them
out into a separate CL with the intent of landing it first, so that it's
easier to see the difference these CLs will have on generated bytecode.
BUG=v8:5855
TBR=tebbi@chromium.org, rmcilroy@chromium.org
Change-Id: Ib84e65847d7396e31b0e38d28f59454cf7c58fc1
Reviewed-on: https://chromium-review.googlesource.com/558221
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46370}
This CL updates the wasm spec tests. In addition it adds an
assertNotEquals function to mjsunit.js, and it fixes the test harness
to not call quit() because it causes a dead-lock in combination with
async compilation.
R=rossberg@chromium.org
Change-Id: I50cf737993adb3e2bd27977efe7e20e304b89078
Reviewed-on: https://chromium-review.googlesource.com/558077
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46366}
The `FAST_` prefix doesn’t make much sense — they’re all just different cases
with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
This patch renames the FAST elements kinds as follows:
- e.g. FAST_ELEMENTS => PACKED_ELEMENTS
- e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
The following exceptions are left intact, for lack of a better name:
- FAST_SLOPPY_ARGUMENTS_ELEMENTS
- SLOW_SLOPPY_ARGUMENTS_ELEMENTS
- FAST_STRING_WRAPPER_ELEMENTS
- SLOW_STRING_WRAPPER_ELEMENTS
This makes it easier to reason about elements kinds, and less confusing to
explain how they’re used.
R=jkummerow@chromium.org, cbruni@chromium.org
BUG=v8:6548
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
Reviewed-on: https://chromium-review.googlesource.com/556032
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46361}
V8's catch prediction mechanism tries to predict whether a thrown
exception will be caught, just by looking at the current call stack.
At the time when catch prediction was first introduced, only a few
builtins (mostly related to Promise and Generator) could end up being
fed into the catch prediction mechanism. This is no longer the case now
that builtins are used in new ways, e.g. Array.p.forEach's continuation
builtins.
This CL removes the need to explicitly mark all builtins visible to the
StackFrameIterator as CAUGHT/UNCAUGHT/PROMISE, and instead defaults to
treating unmarked builtins as UNCAUGHT.
BUG=v8:6536
Change-Id: Ibdc106a91b2b0ffb93099433077642cad02c71e2
Reviewed-on: https://chromium-review.googlesource.com/555518
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46357}
... and set the instance class name in a bootstrapper instead.
Change-Id: Ie8a9a0e7cdc22ca19616b4a0d09665e059cd4d3e
Reviewed-on: https://chromium-review.googlesource.com/557864
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46356}
With FCG no longer able to deoptimize, we can remove the "push" version
of output frame state combine, as deoptimisation to bytecode is always
the PokeAt variant.
Bug: v8:6409
Change-Id: I9b6d38a7441ca834835615c238228fa8a75a027b
Reviewed-on: https://chromium-review.googlesource.com/557866
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46355}
This reverts commit 1520a8518a.
Reason for revert: This CL does not do what it should. All tasks which access the isolate have to be cancelable to guarantee that the isolate still exists when the task is executed. Foreground compilation tasks access the isolate, so they cannot be just normal tasks.
Original change's description:
> [wasm] Run foreground compilation tasks as normal tasks
>
> This CL makes foreground compilation tasks normal (i.e. not cancelable)
> again, because otherwise a deadlock can happen. I think the reason why
> the foreground tasks were cancelable was to make sure that all tasks
> either finish correctly or get canceled. However, since the isolate can
> only shut down on the main thread, this means that the foreground task
> should have already finished when the isolate shuts down, or it should
> not have started at all. I reordered the deletion of the AsyncCompileJob
> though to make sure that an AsyncCompileJob is removed from
> CompilationManager before its promise is resolved.
>
> Here is the deadlock: The JS code which is executed after a promise is
> resolved is executed within the task which resolves the promise. In case
> of async compilation this means that some JS code is executed within a
> CompileTask. In JS, the shutdown of the isolate can be triggered. During
> the shutdown of the isolate, the CancelableTaskManager waits for all
> registered cancelable tasks to complete, including the CompileTask of
> async compilation. This means that the CancelableTaskManager waits for
> itself to finish, which is a deadlock.
>
> R=clemensh@chromium.org, mtrofin@chromium.org
>
> Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
> Reviewed-on: https://chromium-review.googlesource.com/554733
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46343}
TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I60fab90b46d70c703d827816503e7e23b8c50251
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558284
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46353}
This CL landed on top of another CL which I want to revert.
This reverts commit 27b0d6a9fc.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [wasm] Update spec tests
>
> Update the spec tests in v8 to the most recent version.
>
> R=rossberg@chromium.org
> CC=titzer@chromium.org
>
> Change-Id: Ib4e809c20150502b131a2c0b68fdb2ede1d5f85f
> Reviewed-on: https://chromium-review.googlesource.com/552155
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46346}
TBR=mstarzinger@chromium.org,rossberg@chromium.org,ahaas@chromium.org
Change-Id: I82e4a2887bcb867d3572b78c36a20adc05df0903
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558040
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46352}
This reverts commit ca93156294.
Reason for revert: tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/16007
Original change's description:
> [wasm] Allow the initialization of a single compilation unit
>
> This CL adds a new function {InitializeCompilationUnit} to initialize
> a single compilation unit and not just all compilation units at once.
> This is necessary for streaming compilation eventually. This also
> required some refactoring on how the working queue for compilation units
> works. Previously the synchronization was done with an atomic counter,
> now it is done with a lock. Note that the code to finish compilation
> of a module still only works if the working queue gets only empty when
> all work is done. I plan to change this in a different CL.
>
> Since the code would not be tested without streaming compilation, I added
> an experimental flag and a test to test the new code.
>
> R=clemensh@chromium.org, mtrofin@chromium.org
>
> Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
> Reviewed-on: https://chromium-review.googlesource.com/550096
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46348}
TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: Ied6532f05463c0b78c8b8f5307d44640bcca8316
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558224
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46350}
This reverts commit 0d2ed6c328.
The CL introduced perf regressions: crbug.com/735649.
We are going to reland the CL in an isolated V8 roll to ensure
that perf regressions are attributed correctly.
Original commit message:
> [heap] Allow a minimum semi-space size of 512K.
> This CL also reduces the minimum semi-space size to 512K.
> BUG=chromium:716032
BUG=chromium:735649
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I1f1b08ca6853347c00070f000c309d839ff8a4bb
Reviewed-on: https://chromium-review.googlesource.com/552541
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46349}
This CL adds a new function {InitializeCompilationUnit} to initialize
a single compilation unit and not just all compilation units at once.
This is necessary for streaming compilation eventually. This also
required some refactoring on how the working queue for compilation units
works. Previously the synchronization was done with an atomic counter,
now it is done with a lock. Note that the code to finish compilation
of a module still only works if the working queue gets only empty when
all work is done. I plan to change this in a different CL.
Since the code would not be tested without streaming compilation, I added
an experimental flag and a test to test the new code.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
Reviewed-on: https://chromium-review.googlesource.com/550096
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46348}
This way, each lazy function needs to handle only the data relevant to
itself. This reduced data handling overheads.
Other changes:
1) Don't deserialize the data; once it's on the heap, it can stay there. Lazy
function compilation is only done in the main thread.
2) Separate ProducedPreParsedScopeData and ConsumedPreParsedScopeData. It's clearer, because:
- The data looks fundamentally different when we're producing it and when we're
consuming it.
- Cleanly separates the operations we can do in the "producing phase" and in the
"consuming phase".
Bug: v8:5516
Change-Id: I6985a6621f71b348a55155724765624b5d5f7c33
Reviewed-on: https://chromium-review.googlesource.com/528094
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46347}
Update the spec tests in v8 to the most recent version.
R=rossberg@chromium.orgCC=titzer@chromium.org
Change-Id: Ib4e809c20150502b131a2c0b68fdb2ede1d5f85f
Reviewed-on: https://chromium-review.googlesource.com/552155
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46346}
This CL makes foreground compilation tasks normal (i.e. not cancelable)
again, because otherwise a deadlock can happen. I think the reason why
the foreground tasks were cancelable was to make sure that all tasks
either finish correctly or get canceled. However, since the isolate can
only shut down on the main thread, this means that the foreground task
should have already finished when the isolate shuts down, or it should
not have started at all. I reordered the deletion of the AsyncCompileJob
though to make sure that an AsyncCompileJob is removed from
CompilationManager before its promise is resolved.
Here is the deadlock: The JS code which is executed after a promise is
resolved is executed within the task which resolves the promise. In case
of async compilation this means that some JS code is executed within a
CompileTask. In JS, the shutdown of the isolate can be triggered. During
the shutdown of the isolate, the CancelableTaskManager waits for all
registered cancelable tasks to complete, including the CompileTask of
async compilation. This means that the CancelableTaskManager waits for
itself to finish, which is a deadlock.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
Reviewed-on: https://chromium-review.googlesource.com/554733
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46343}
This mostly reverts commit c503b80595 but fixes
an issue where literals would always be pretenured on first instantiation.
As a cleanup we pass in a PretenureFlag instead of using the FeedbackVector as
indicator.
Bug: v8:6211
Change-Id: Id328552620e33f5083519bcba1e24396d162d516
Reviewed-on: https://chromium-review.googlesource.com/555670
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46342}
Similar to JSCall, we can also replace uninitialized JSConstruct nodes
with SOFT deopts to ensure that we don't generate unnecessary dead code.
This for example shows up in the hot parts of the Node event emitter
currently where the generic code for handling events with 4 or more
parameters might not have been run, but we still generate most of the
code because the new Array call in the beginning is not turned into
a SOFT deopt immediately.
Drive-by-fix: Also refactor the BytecodeGraphBuilder's handling of
Construct bytecodes a bit to reduce the amount of code duplication.
BUG=v8:4551, v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2958253002
Cr-Commit-Position: refs/heads/master@{#46339}
Previously V8 created a promise to return to userland,
but instead we let the embedder create and track the promise.
Bug: v8:5785
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I8903ffbabf3a256f1c8df844a656a873da304586
Reviewed-on: https://chromium-review.googlesource.com/492646
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46333}
The naming convention in v8 has trivial getters named like the field,
no 'get_' prefix, and dropping the '_' suffix of the field.
BUG=
Review-Url: https://codereview.chromium.org/2958283003
Cr-Commit-Position: refs/heads/master@{#46332}
When internalization of the key fails because the string does not
exist in the StringTable yet, then no regular object can possibly
have a property with that name, so just returning "false" is safe.
However, for objects with interceptors this is not true, as there
may well be intercepted properties whose keys have not been
internalized. So "special API objects" must take the slow path to
query any interceptors.
Bug: chromium:735990
Change-Id: Ibe6c4f8b14fef65738115f12167d3602bec3d9b7
Reviewed-on: https://chromium-review.googlesource.com/552550
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46323}
