Simplify the logic in the CompilerDispatcher to use BackgroundCompileTasks
directly, rather than having a (now unecessary) CompilerDispatcherJob
abstraction. In the process, the CompilerDispatcherTracer is removed, and the
idle task logic is simplified finalize already compiled jobs until the
idle task deadline.
BUG=v8:8238, v8:8041
Change-Id: I1ea2366f959b6951de222d62fde80725b3cc70ff
Reviewed-on: https://chromium-review.googlesource.com/c/1260123
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56473}
This will avoid queueing the error for any valid-syntax JS, whereas currently
we'll queue it for any assignment expression that doesn't look like the start
of an arrow function.
The final error will look the same even if we delay queueing it. Since the
formals weren't parenthesized we won't actually throw the queued error, but the
tracked "binding pattern error".
Change-Id: I80e9d8ef4fb8244829c274a7d656637080583769
Reviewed-on: https://chromium-review.googlesource.com/c/1270583
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56469}
This flag has been on by default for some time. Once
https://chromium-review.googlesource.com/c/v8/v8/+/1270578 lands we need it to
be able to find duplicate parameters (to be spec-compliant).
Change-Id: I222023d7cd955127d3ecca42283b37063e962c58
Reviewed-on: https://chromium-review.googlesource.com/c/1270581
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56468}
Now duplicate parameter detection depends on tracking of unresolved references.
This also fixes finding duplicate parameters of arrow functions nested in other
arrow functions.
Change-Id: I644bfdc513244637345c1069e5c7e5fde713da63
Reviewed-on: https://chromium-review.googlesource.com/c/1270578
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56467}
... by removing entries corresponding to read only roots (which are
immortal immovable by definition) and using READ_ONLY_ROOT_LIST explicitly.
This CL also renames the list to MUTABLE_IMMORTAL_IMMOVABLE_ROOT_LIST and
moves Heap::RootIsImmortalImmovable() to RootsTable::IsImmortalImmovable().
Bug: v8:8238
Change-Id: I3e44a06d7a816955bc3471e788e883fb053b03d9
Reviewed-on: https://chromium-review.googlesource.com/c/1269035
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56466}
The regexp for finding resources to be pushed to Android devices was
too lax. On empty strings it tried to check for more resources on a
directory and hung.
The last test262 roll contains tests with empty imports that started
hanging in this way.
TBR=neis@chromium.org
NOTRY=true
Bug: v8:7834
Change-Id: Ie58f1b18bdd99b7b40c1fb39b25e2f481932e0f3
Reviewed-on: https://chromium-review.googlesource.com/c/1270579
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56465}
This addresses bunch of problems introduced by the attempt to
remove indexing by function names
https://chromium-review.googlesource.com/c/1267496.
Now I tested with the right version of the file :-)
Change-Id: Idfc8a17a0890d0453d14b949388c34c36a0b64f5
Reviewed-on: https://chromium-review.googlesource.com/c/1270575
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56463}
Also move some code from separated function into
JSDateTimeFormat::Initialize as suggested in review of previous CL.
Bug: v8:8066
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I6be61482759aa54890e8f9d86483436a1abcde87
Reviewed-on: https://chromium-review.googlesource.com/c/1252882
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56459}
Fix spec non compliance by only trimming the unicode locales and not
all extensions.
Remove regexp and just use straightforward string manipulation.
Bug: v8:5751
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ie95828a8f62834daf8cde189f408e95a14e796fe
Reviewed-on: https://chromium-review.googlesource.com/c/1255556
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56458}
Move strings in heap-symbols.h that only used inside V8_INTL_SUPPORT
under INTERNALIZED_STRING_LIST_GENERATOR_INTL so non intl users won't
use unnecessary memory. Also avoid two NewStringFromStaticChars calls
for string already defined in heap-symbols.h.
Bug: v8:8256
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I65dbc34639064d6d4c7d1786405b8b3af666bc2a
Reviewed-on: https://chromium-review.googlesource.com/c/1268761
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56456}
The notification is only used for testing and benchmarking purposes.
Announcing low memory is usually done using MemoryPressure API.
Bug: chromium:843903
Change-Id: I998018f7f5f3a0d06283aa6010228a9c86f12c39
Reviewed-on: https://chromium-review.googlesource.com/c/1269037
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56454}
The Parser desugaring didn't use the AsyncReturnStatement consistently
to return from async functions (aka resolve the .promise with the return
value and return the .promise from the async function). Instead the
Parser essentially had a copy of the BytecodeGenerator functionality.
This change unifies the handling of returns from async functions.
Bug: v8:7522, v8:8238
Change-Id: Ib00a60aee30d541b84835d9cc83e9937b7a39e26
Reviewed-on: https://chromium-review.googlesource.com/c/1269036
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56453}
Reading through some code today I happened to notice a few places where
we were passing "ok" instead of "CHECK_OK", leading to the possibility
of code continuing on past a syntax error. This fixes all such
cases I found (through manual inspection) in parser-base.h
Change-Id: I95ef0a08d0e0a537d86a73bb62929842a3f57a31
Reviewed-on: https://chromium-review.googlesource.com/c/1262998
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56452}
When Turbofan gets triggered during bootstrapping (via --always-opt), some
context fields still hold undefined rather than their actual value.
Bug: v8:7790
Change-Id: Id87c593182fa8450ba9415d144d105281e48236f
Reviewed-on: https://chromium-review.googlesource.com/c/1268240
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56449}
In the process:
- Convert TryLabelStatements into TryLabelExpressions
- Change TryLabelExpressions to support only single label blocks and de-sugar
try/labels into nested try/label statements. This allows the code in a label
block to goto subsequent labels in the same try/label statement.
- Make otherwise expressions either take IdentifierExpressions which get
converted into simple label names OR atomarStatements, which make useful
non-label operations, like 'break' and 'continue', useful together with
otherwise. Non-label otherwise statements get de-sugared into try/label
blocks.
Bug: v8:7793
Change-Id: Ie56ede6306e2a3182f6aa1bb8750ed418bda01db
Reviewed-on: https://chromium-review.googlesource.com/c/1266997
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56447}
This adds basic support for decoding catch-all expressions as part of a
try block. Note that control flow and code generation support is still
missing.
R=clemensh@chromium.org
TEST=unittests/FunctionBodyDecoderTest.TryCatchAll
BUG=v8:8091
Change-Id: I10a1aa3e3e0418e0a04965e8318c94f449a00bb4
Reviewed-on: https://chromium-review.googlesource.com/c/1268059
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56444}
See https://chromium-review.googlesource.com/1219025 for the corresponding
MaybeObject renaming.
BUG=v8:7308
Change-Id: Ib454fd53d12f110da289e1d3e1e12411b016e557
Reviewed-on: https://chromium-review.googlesource.com/c/1267937
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56443}
This adds support to the escape analysis to allow scalar replacement
of (small) FixedArrays with element accesses where the index is not a
compile time constant. This happens quite often when inlining functions
that operate on variable number of arguments. For example consider this
little piece of code:
```js
function sum(...args) {
let s = 0;
for (let i = 0; i < args.length; ++i) s += args[i];
return s;
}
function sum2(x, y) {
return sum(x, y);
}
```
This example is made up, of course, but it shows the problem. Let's
assume that TurboFan inlines the function `sum` into it's call site
at `sum2`. Now it has to materialize the `args` array with the two
values `x` and `y`, and iterate through these `args` to sum them up.
The escape analysis pass figures out that `args` doesn't escape (aka
doesn't outlive) the optimized code for `sum2` now, but TurboFan still
needs to materialize the elements backing store for `args` since there's
a `LoadElement(args.elements,i)` in the graph now, and `i` is not a
compile time constant.
However the escape analysis has more information than just that. In
particular the escape analysis knows exactly how many elements a non
escaping object has, based on the fact that the allocation must be
local to the function and that we only track objects with known size.
So in the case above when we get to `args[i]` in the escape analysis
the relevant part of the graph looks something like this:
```
elements = LoadField[elements](args)
length = LoadField[length](args)
index = CheckBounds(i, length)
value = LoadElement(elements, index)
```
In particular the contract here is that `LoadElement(elements,index)`
is guaranteed to have an `index` that is within the valid bounds for
the `elements` (there must be a preceeding `CheckBounds` or some other
guard in optimized code before it). And since `elements` is allocated
inside of the optimized code object, the escape analysis also knows
that `elements` has exactly two elements inside (namely the values of
`x` and `y`). So we can use that information and replace the access
with a `Select(index===0,x,y)` operation instead, which allows us to
scalar replace the `elements`, since there's no escaping use anymore
in the graph.
We do this for the case that the number of elements is 2, as described
above, but also for the case where elements length is one. In case
of 0, we know that the `LoadElement` must be in dead code, but we can't
just mark it for deletion from the graph (to make sure it doesn't block
scalar replacement of non-dead code), so we don't handle this for now.
And for one element it's even easier, since the `LoadElement` has to
yield exactly said element.
We could generalize this to handle arbitrary lengths, but since there's
a cost to arbitrary decision trees here, it's unclear when this is still
beneficial. Another possible solution for length > 2 would be to have
special stack allocation for these backing stores and do variable index
accesses to these stack areas. But that's way beyond the scope of this
isolated change.
This change shows a ~2% improvement on the EarleyBoyer benchmark in
JetStream, since it benefits a lot from not having to materialize these
small arguments backing stores.
Drive-by-fix: Fix JSCreateLowering to properly initialize "elements"
with StoreElement instead of StoreField (which violates the invariant
in TurboFan that fields and elements never alias).
Bug: v8:5267, v8:6200
Change-Id: Idd464a15a81e7c9653c48c814b406eb859841428
Reviewed-on: https://chromium-review.googlesource.com/c/1267935
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56442}
This change adds predicates to check whether a given JavaScript operator
needs the "current context" or if any surrounding context (including the
"native context") does it. For example JSAdd doesn't ever need the
current context, but actually only the native context. In the
BytecodeGraphBuilder we use this predicate to check whether a given
operator needs the current context, and if not, we just pass in the
native context.
Doing so we improve the performance on the benchmarks given in the
tracking bug significantly, and go from something around
arrayMap: 476 ms.
arrayFilter: 312 ms.
arrayEvery: 241 ms.
arraySome: 152 ms.
to
arrayMap: 377 ms.
arrayFilter: 296 ms.
arrayEvery: 191 ms.
arraySome: 91 ms.
which is an up to 40% improvement. So for idiomatic modern JavaScript
which uses higher order functions quite a lot, not just the builtins
provided by the JSVM, this is going to improve peak performance
noticably.
This also makes it possible to completely eliminate all the allocations
in the aliased sloppy arguments example
```js
function foo(a) { return arguments.length; }
```
concretely we don't allocate the function context anymore and we also
don't allocate the arguments object anymore (the JSStackCheck was the
reason why we did this in the past, because it was holding on to the
current context, which also kept the allocation for the arguments
alive).
Bug: v8:6200, v8:8060
Change-Id: I1db56d00d6b510ce6337608c0fff16af96e95eef
Design-Document: bit.ly/v8-turbofan-context-sensitive-js-operators
Reviewed-on: https://chromium-review.googlesource.com/c/1267176
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56441}
On windows, the {NativeModule::committed_code_space_} counter can underflow because
of a bug. This propagates to {WasmCodeManager::remaining_uncommitted_code_space_},
which can lead to over-allocation (more than {kMaxWasmCodeMemory} bytes of code
space per module).
We were also seeing this bug on UMA data (>1024 MB code space usage).
R=ahaas@chromium.org
Bug: chromium:893096
Change-Id: If3c9b3e7bdc9fc3caf1eccae991123409718b90f
Reviewed-on: https://chromium-review.googlesource.com/c/1267943
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56440}
This is a reland of ef2a19a211.
Use AllocateJSArray to avoid allocating an empty fixed array.
Original change's description:
> Add fast path for spreading primitive strings.
>
> This improves the performance on primitive strings of
> IterableToListWithSymbolLookup, which implements the
> CreateArrayFromIterable bytecode. The fast path is only
> taken if the string iterator protector is valid (that is,
> String.prototype[Symbol.iterator] and
> String.prototype[Symbol.iterator]().next are untouched).
>
> This brings spreading of primitive strings closer to the
> performance of the string iterator optimizations.
> (see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/).
>
> Bug: chromium:881273, v8:7980
> Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a
> Reviewed-on: https://chromium-review.googlesource.com/1243110
> Commit-Queue: Hai Dang <dhai@google.com>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56329}
Bug: chromium:881273, v8:7980
Change-Id: I746c57ddfc300e1032057b5125bc824adf5c2cd3
Reviewed-on: https://chromium-review.googlesource.com/c/1267497
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56438}
When generating code for element accesses, we used to constant-fold
JSTypedArray receivers even when their buffers were on the JS heap.
This required a call to MaterializeArrayBuffer, which hinders
background compilation. Since the benefit of this optimization is
believed to be small, we decided to remove it.
Bug: v8:7790
Change-Id: I28d3a57b3d8f5b58b6e00e0bb8328b682a6fbd88
Reviewed-on: https://chromium-review.googlesource.com/c/1256831
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56434}
Return the actual length even when the buffer is neutered (we used
to return 0). This avoids confusion and makes the behavior consistent
with byte_offset() and byte_length().
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I998f12fa4a428f8555f62e1535247f571ab053f2
Reviewed-on: https://chromium-review.googlesource.com/c/1256768
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56433}
Using function ids is more reliable since there can be several functions
or scripts with the same name. Also, that way we do not have to parse
anything.
Change-Id: If657141d0d6e27dabb49456e0275cce65e753541
Reviewed-on: https://chromium-review.googlesource.com/c/1267496
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56431}
In the JSCallReducer, the lowering for Array#filter(), Array#some() and
Array#every() properly converted the outcome of the predicate call to
boolean using the ToBoolean conversion, but then also added a redundant
ReferenceEqual comparison with true. This particular pattern is not
optimized by TurboFan, since it can never happen using the regular
comparison machinery. So remove the unnecessary ReferenceEqual and just
do the ToBoolean in the JSCallReducer.
Bug: v8:8238
Change-Id: Ic2585431b4b75d3d5f978c85156cfb19738b7ae6
Reviewed-on: https://chromium-review.googlesource.com/c/1267177
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56430}
As identified in the web-tooling-benchmark, there are specific code
patterns involving array indexed property accesses and subsequent
comparisons of those indices that lead to repeated Smi checks in the
optimized code, which in turn leads to high register pressure and
generally bad register allocation. An example of this pattern is
code like this:
```js
function f(a, n) {
const i = a[n];
if (n >= 1) return i;
}
```
The `a[n]` property access introduces a CheckBounds on `n`, which
later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`,
however the `n >= 1` comparison has collected `SignedSmall` feedback
and so it introduces a `CheckedTaggedToTaggedSigned` operation. This
second Smi check is redundant and cannot easily be combined with the
earlier tagged->int32 conversion, since that also deals with heap
numbers and even truncates -0 to 0.
So we teach the RedundancyElimination to look at the inputs of these
speculative number comparisons and if there's a leading bounds check
on either of these inputs, we change the input to the result of the
bounds check. This avoids the redundant Smi checks later and generally
allows the SimplifiedLowering to do a significantly better job on the
number comparisons. We only do this in case of SignedSmall feedback
and only for inputs that are not already known to be in UnsignedSmall
range, to avoid doing too many (unnecessary) expensive lookups during
RedundancyElimination.
All of this is safe despite the fact that CheckBounds truncates -0
to 0, since the regular number comparisons in JavaScript identify
0 and -0 (unlike Object.is()). This also adds appropriate tests,
especially for the interesting cases where -0 is used only after
the code was optimized.
Bug: v8:6936, v8:7094
Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07
Reviewed-on: https://chromium-review.googlesource.com/c/1246181
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56428}
This reverts commit 4fd92b252b.
Reason for revert: Significant tankage on the no-mitigations bots (bad timing on the regular bots)
Original change's description:
> [turbofan] Do not consume SignedSmall feedback in TurboFan anymore.
>
> This changes TurboFan to treat SignedSmall feedback similar to Signed32
> feedback for binary and compare operations, in order to simplify and
> unify the machinery.
>
> This is an experiment. If this turns out to tank performance, we will
> need to revisit and ideally revert this change.
>
> Bug: v8:7094
> Change-Id: I885769c2fe93d8413e59838fbe844650c848c3f1
> Reviewed-on: https://chromium-review.googlesource.com/c/1261442
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56411}
TBR=jarin@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7094
Change-Id: I9fff3b40e6dc0ceb7611b55e1ca9940089470404
Reviewed-on: https://chromium-review.googlesource.com/c/1267175
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56427}
Add necessary dependencies and rules to produce a functional
Fuchsia d8 package from a standalone V8 build.
R=adamk
BUG=
Change-Id: If81cc9fc37822cda47bb1fe1846b9519c8fcbf40
Reviewed-on: https://chromium-review.googlesource.com/c/1226414
Commit-Queue: Dimitri Glazkov <dglazkov@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56425}
