This migrates the test configurations of all builders on the main
console (aka client.v8) to the V8 repository, preparing removal from
build/scripts/slave/recipe_modules/v8/builders.py.
NOTRY=true
Bug: chromium:830557
Change-Id: I40b8f31ab48426c7122c87e0221d6f05dc205e81
Reviewed-on: https://chromium-review.googlesource.com/c/1273237
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56547}
Use naming similar to the spec: "table" instead of "function table",
"element segment" instead of "function table init".
Change-Id: Ib1b6cdfa566f8bd00017ccedf9440084204f10ff
Reviewed-on: https://chromium-review.googlesource.com/c/1273612
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56545}
This reverts commit fa65063a98.
Reason for revert:
This changes API contract with Blink as some state is destroyed before
actually tearing down the Isolate. Flushing the second round tasks
then tries to access various state that is already gone on the Blink
side. See bugs.
Bug: chromium:893944, chromium:893549, chromium:890631
Original change's description:
> [heap] Run phantom handle callbacks on tear down
>
> Pending phantom handle callbacks are not reliably executed if the heap
> shuts down. This can cause to memory leaks or other unwanted behaviour,
> like in wasm where the NativeModules (held in Managed objects
> implemented via phantom handles) unregister from the WasmEngine in the
> second-pass callback. This must be executed before tearing down the
> WasmEngine.
>
> This CL fixes this by running pending callback synchronously on heap
> tear down.
>
> R=ulan@chromium.org, mlippautz@chromium.org
>
> Bug: v8:8208
> Change-Id: I27b630c4d8f1fb12309040ea2179b64eed38710a
> Reviewed-on: https://chromium-review.googlesource.com/1249101
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56286}
TBR=ulan@chromium.org,mlippautz@chromium.org,clemensh@chromium.org
Bug: v8:8208
Change-Id: I4b403fd84473edb8895c3725ff3348574c54247b
Reviewed-on: https://chromium-review.googlesource.com/c/1274085
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56542}
Port a2b3480611
Original Commit Message:
This CL refactors the implementation of WASM->JS import wrappers in order
to make the wrapper code shareable. Instead of specializing to the import
index, we use a tuple as the object ref in the both the import and indirect
tables. The tuple allows the wrapper code to load both the calling
instance and the target callable, rather than relying on code specialization.
This requires some tricky codegen machinery, because WASM call descriptors
expect an instance argument in a given register, yet the wrappers receive
a tuple, the code generator must generate a prologue that loads the
instance (and the callable), since it is not possible to express this at
the graph level.
R=titzer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I34302b8ff737296fc98c032f1e9848b4bb9fae13
Reviewed-on: https://chromium-review.googlesource.com/c/1273866
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56541}
Pass on information about the embedder state using the fact that tasks
are run from top level
Bug: chromium:893944
Change-Id: I01441778770c5acc784540e496eec5c3fdb87796
Reviewed-on: https://chromium-review.googlesource.com/c/1273048
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56540}
The NumberMultiply typing rule gave up in the presence of NaN inputs,
but we can still infer useful ranges here and just union the result
of that with the NaN propagation (similar for MinusZero propagation).
This way we can still makes sense of these ranges at the uses.
Bug: v8:8015
Change-Id: Ic4c5e8edc6c68776ff3baca9628ad7de0f8e2a92
Reviewed-on: https://chromium-review.googlesource.com/c/1261143
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56539}
Port 4cbec82cbe
Original Commit Message:
Pure refactoring CL. Introduce a symbolic name for the register
used to hold the function index when calling the lazy compile stub.
This makes it easier to see this contract when looking at the
macro assembler.
R=titzer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I320373dfe4734b27b85217a829bf574bc7b90a2d
Reviewed-on: https://chromium-review.googlesource.com/c/1273825
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56536}
a) The current size of the backing store for the array under splice
wasn't considered. Additionally, allocate the array with the
normal growing strategy.
b) Use primitives memcpy and memmove when
appropriate. These calls are wrapped in new CSA functions
MoveElements and CopyElements, which use the C functions when a
write barrier isn't needed (otherwise they just copy elements
in a loop).
Bug: chromium:880780
Change-Id: I39a917c71036f52250c68f2cced77a1c24f97b67
Reviewed-on: https://chromium-review.googlesource.com/c/1243104
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56534}
libc++'s _LIBCPP_DEBUG gets upset when comparators take non-const
references.
Bug: chromium:893810
Change-Id: I838ff08bfd53893984f0ce41a9d78d6f1d80a324
Reviewed-on: https://chromium-review.googlesource.com/c/1272184
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56533}
Disable a new test that triggers a known issue with the arguments
adaptor trampoline.
TBR=jgruber@chromium.org
Change-Id: Id89b71e49e5dbef06d75758d98ed162c07fc34f4
Bug: v8:6666
Reviewed-on: https://chromium-review.googlesource.com/c/1273052
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56532}
Block coverage is based on a system of ranges that can either have
both a start and end position, or only a start position (so-called
singleton ranges). When formatting coverage information, singletons
are expanded until the end of the immediate full parent range. E.g.
in:
{0, 10} // Full range.
{5, -1} // Singleton range.
the singleton range is expanded to {5, 10}.
Singletons are produced mostly for continuation counters that track
whether we execute past a specific language construct.
Unfortunately, continuation counters can turn up in spots that confuse
our post-processing. For example:
if (true) { ... block1 ... } else { ... block2 ... }
If block1 produces a continuation counter, it could end up with the
same start position as the else-branch counter. Since we merge
identical blocks, the else-branch could incorrectly end up with an
execution count of one.
We need to avoid merging such cases. A full range should always take
precedence over a singleton range; a singleton range should never
expand to completely fill a full range. An additional post-processing
pass ensures this.
Bug: v8:8237
Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf
Reviewed-on: https://chromium-review.googlesource.com/c/1273095
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56531}
The MapIterator protector protects the original iteration behaviors of
Map.prototype.keys(), Map.prototype.values(), and Set.prototype.entries().
It does not protect the original iteration behavior of
Map.prototype[Symbol.iterator](). The protector is invalidated when:
* The 'next' property is set on an object where the property holder is the
%MapIteratorPrototype% (e.g. because the object is that very prototype).
* The 'Symbol.iterator' property is set on an object where the property
holder is the %IteratorPrototype%. Note that this also invalidates the
SetIterator protector (see below).
The SetIterator protector protects the original iteration behavior of
Set.prototype.keys(), Set.prototype.values(), Set.prototype.entries(),
and Set.prototype[Symbol.iterator](). The protector is invalidated when:
* The 'next' property is set on an object where the property holder is the
%SetIteratorPrototype% (e.g. because the object is that very prototype).
* The 'Symbol.iterator' property is set on an object where the property
holder is the %SetPrototype% OR %IteratorPrototype%. This means that
setting Symbol.iterator on a MapIterator object can also invalidate the
SetIterator protector, and vice versa, setting Symbol.iterator on a
SetIterator object can also invalidate the MapIterator. This is an over-
approximation for the sake of simplicity.
Bug: v8:7980
Change-Id: I54ad6e4c7f19ccc27d7001f6c4b6c8d6ea4ee871
Reviewed-on: https://chromium-review.googlesource.com/c/1273102
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#56530}
1) As found by the GC fuzzer: missing HandleScopes.
2) The RecordSlot barrier was missing for NativeContext::AddDirtyJSWeakFactory.
3) Need Context::Scope to surround the cleanup function (if it results in an
error, we try to get native_context() from Isolate).
BUG=v8:8179,v8:8286
Change-Id: I2d995a76770658848e3c9629333bedbc2ef43b82
Reviewed-on: https://chromium-review.googlesource.com/c/1273051
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56529}
The API will be used to post GC tasks that benefit from being executed
at top level.
Bug: chromium:843903
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I062855e810ca9a8d8af8ae8b66e02c85e108798b
Reviewed-on: https://chromium-review.googlesource.com/c/1273045
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56528}
Now that import wrappers are no longer specialized to an index, they
can be cached in the native module, keyed by
(WasmImportCallKind, FunctionSig). This saves instantiation time and
also fixes a (slow) memory leak.
R=mstarzinger@chromium.org
Change-Id: I5197bbfae79d6e811a01289b990db445373eea6c
Reviewed-on: https://chromium-review.googlesource.com/c/1270943
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56526}
An asan bug on Windows breaks the chrome asan bot. This disables asan
for the Torque build step as a workaround.
Bug: chromium:893437
Change-Id: I4ccc25e7667abb3ea167c3e8af1210685ff06b9e
Reviewed-on: https://chromium-review.googlesource.com/c/1273105
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56523}
This CL refactors the implementation of WASM->JS import wrappers in order
to make the wrapper code shareable. Instead of specializing to the import
index, we use a tuple as the object ref in the both the import and indirect
tables. The tuple allows the wrapper code to load both the calling
instance and the target callable, rather than relying on code specialization.
This requires some tricky codegen machinery, because WASM call descriptors
expect an instance argument in a given register, yet the wrappers receive
a tuple, the code generator must generate a prologue that loads the
instance (and the callable), since it is not possible to express this at
the graph level.
R=mstarzinger@chromium.orgCC=clemensh@chromium.org
Change-Id: Id67e307f7f5089e776f5439a53b5aee4b76934b6
Reviewed-on: https://chromium-review.googlesource.com/c/1268237
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56520}
This is a reland of 22b56f47e3
Nothing has changed. This is a reland of a speculative revert.
Original change's description:
> [snapshot] Factor out root serialization code
>
> Factors out a new method Serializer::SerializeRoot which attempts to
> serialize a given object as a Root if it is one and the Serializer's
> policy allows that root to be serialized (implemented as a new virtual
> method RootCanBeSerialized)..
>
> This is in preparation for adding a ReadOnlySerializer which change the
> way read-only roots are serialized.
>
> Bug: v8:8191
> Change-Id: I7fbb4e9520fba8b836a0b6bf95ca39abc3ded79e
> Reviewed-on: https://chromium-review.googlesource.com/c/1264698
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56494}
TBR=jgruber
Bug: v8:8191
Change-Id: I30a606b9c99f5651fae323d12f8f74b13bb085fa
Reviewed-on: https://chromium-review.googlesource.com/c/1273103
Reviewed-by: Dan Elphick <delphick@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56519}
Pure refactoring CL. Introduce a symbolic name for the register
used to hold the function index when calling the lazy compile stub.
This makes it easier to see this contract when looking at the
macro assembler.
R=ahaas@chromium.orgCC=clemensh@chromium.org
Change-Id: I714f978883ced001a1435338dcefd96744bfb2ae
Reviewed-on: https://chromium-review.googlesource.com/c/1273099
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56516}
Before adding another test for removing breakpoint, this CL modernizes
the existing test for setting breakpoints.
R=kozy@chromium.orgCC=ahaas@chromium.org
Bug: chromium:837572
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I642f9673f327f4ec569a4f67a61b5e264cf25b8f
Reviewed-on: https://chromium-review.googlesource.com/c/1264636
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56514}
This reverts commit 471fef0469.
Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.
Original change's description:
> [coverage] change block range to avoid ambiguity.
>
> By moving the block range end to left of closing bracket,
> we can avoid ambiguity where an open-ended singleton range
> could be both interpreted as inside the parent range, or
> next to it.
>
> R=verwaest@chromium.org
>
> Bug: v8:8237
> Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
> Reviewed-on: https://chromium-review.googlesource.com/1254127
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56347}
TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8237
Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
Reviewed-on: https://chromium-review.googlesource.com/c/1273096
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56513}
This reverts commit 22b56f47e3.
Reason for revert: Speculatively reverting because it increases Android binary size unexpectedly, see https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-binary-size/72572
Original change's description:
> [snapshot] Factor out root serialization code
>
> Factors out a new method Serializer::SerializeRoot which attempts to
> serialize a given object as a Root if it is one and the Serializer's
> policy allows that root to be serialized (implemented as a new virtual
> method RootCanBeSerialized)..
>
> This is in preparation for adding a ReadOnlySerializer which change the
> way read-only roots are serialized.
>
> Bug: v8:8191
> Change-Id: I7fbb4e9520fba8b836a0b6bf95ca39abc3ded79e
> Reviewed-on: https://chromium-review.googlesource.com/c/1264698
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56494}
TBR=jgruber@chromium.org,delphick@chromium.org,ygg@google.com
Change-Id: I7012abec0f33f655efc64dc44f7fa461d7e4b7e9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8191
Reviewed-on: https://chromium-review.googlesource.com/c/1273098
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56509}
This implements the editorial change in https://github.com/tc39/ecma262/pull/1146
which removes the need to allocate the throwaway promise in await (the throwaway
promise was not exposed to user JavaScript anyways, but this spec change allows
us to rely on this behavior). Now we still need the throwaway promise for proper
before and after events with both DevTools (which might change) and PromiseHooks.
So if either DevTools or PromiseHooks is on, we call into %AwaitPromisesInit,
which then allocates the throwaway promise and does all the other debugger/hooks
related setup.
This gives around 7% improvement on the doxbee-async-es2017-native and around 1-2%
on the parallel-async-es2017-native benchmarks.
Bug: v8:7253, v8:8285
Ref: tc39/ecma262#1146
Tbr: ulan@chromium.org
Change-Id: I972ba0538ec8c00808e95b183603025c7e55a6d3
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1270798
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56506}
Divide MarkExpressionAsAssigned into MarkExpressionAsAssigned and
MarkPatternAsAssigned so it's clear when we need to mark just a single variable
or an entire destructuring assignment pattern.
Change-Id: Ia188b3d9b15944a1859676f483df229225ce8404
Reviewed-on: https://chromium-review.googlesource.com/c/1270945
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56505}
This change introduces new intrinsics used to desugar async functions
in the Parser and the BytecodeGenerator, namely we introduce a new
%_AsyncFunctionEnter intrinsic that constructs the generator object
for the async function (and in the future will also create the outer
promise for the async function). This generator object is internal
and never escapes to user code, plus since async functions don't have
a "prototype" property, we can just a single map here instead of tracking
the prototype/initial_map on every async function. This saves one word
per async function plus one initial_map per async function that was
invoked at least once.
We also introduce two new intrinsics %_AsyncFunctionReject, which
rejects the outer promise with the caught exception, and another
%_AsyncFunctionResolve, which resolves the outer promise with the
right hand side of the `return` statement. These functions also perform
the DevTools part of the job (aka popping from the promise stack and
sending the debug event). This allows us to get rid of the implicit
try-finally from async functions completely; because the finally
block only called to the %AsyncFunctionPromiseRelease builtin, which
was used to inform DevTools.
In essence we now turn an async function like
```js
async function f(x) { return await bar(x); }
```
into something like this (in Parser and BytecodeGenerator respectively):
```
function f(x) {
.generator_object = %_AsyncFunctionEnter(.closure, this);
.promise = %AsyncFunctionCreatePromise();
try {
.tmp = await bar(x);
return %_AsyncFunctionResolve(.promise, .tmp);
} catch (e) {
return %_AsyncFunctionReject(.promise, e);
}
}
```
Overall the bytecode for async functions gets significantly shorter
already (and will get even shorter once we put the outer promise into
the async function generator object). For example the bytecode for a
simple async function
```js
async function f(x) { return await x; }
```
goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
is in particular due to the simplification around the try-finally
removal.
Overall this seems to improve the doxbee-async-es2017-native test by
around 2-3%. On the test case mentioned in v8:8276 we go from
1124ms to 441ms, which corresponds to a 60% reduction in total
execution time!
Tbr: marja@chromium.org
Bug: v8:7253, v8:7522, v8:8276
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
Reviewed-on: https://chromium-review.googlesource.com/c/1269041
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56502}
