This reverts commit 3c04ee6d4e.
Reason for revert: Speculative revert for OOMs in:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20shared/builds/18563
Original change's description:
> [heap] Make aborting compaction a fatal
>
> Last attempt failed because of too agressive growing and no proper GC
> scheduling.
>
> Also refactor live object iteration on the way to avoid a branch when we
> know that we will succeed.
>
> Bug: chromium:651354
> Change-Id: I8f52cbc79ac293989fb7c29c492d4ae4afe5ebe4
> Reviewed-on: https://chromium-review.googlesource.com/544829
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46245}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: Ifb9fd0c873c4ec6d4bd895f2978849cc2a223a05
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:651354
Reviewed-on: https://chromium-review.googlesource.com/549324
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46247}
Last attempt failed because of too agressive growing and no proper GC
scheduling.
Also refactor live object iteration on the way to avoid a branch when we
know that we will succeed.
Bug: chromium:651354
Change-Id: I8f52cbc79ac293989fb7c29c492d4ae4afe5ebe4
Reviewed-on: https://chromium-review.googlesource.com/544829
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46245}
Adds a CheckString to all operand inputs of JSStringConcat. The operands are
already known to be strings, so this will get eliminated in almost all cases,
however, if there is a yield within the concatenation then we lose the
knowledge that the previous operands are strings since the values are loaded
from the generator object. Adds a test for this case.
BUG=v8:6243
Change-Id: I1601a316e6efbed1c53486f1027cb0ea023ff030
Reviewed-on: https://chromium-review.googlesource.com/549301
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46243}
This reverts commit 72b88fdab8.
Reason for revert: Changes a layout test:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16595
Original change's description:
> [runtime] Make all built-in functions strict.
>
> According to ES#sec-built-in-function-objects all built-in functions
> must be strict.
>
> This is a preliminary CL before changing the way we define built-in
> functions in native JS files.
>
> Bug: v8:6459
> Change-Id: I8e60b342f04ea1b0843fe1990334cbb9b26ebac4
> Reviewed-on: https://chromium-review.googlesource.com/546215
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46237}
TBR=adamk@chromium.org,ishell@chromium.org,verwaest@chromium.org
Change-Id: Ic458b478b2dd23aae7ea2a51aa6052c1f5931c56
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6459
Reviewed-on: https://chromium-review.googlesource.com/549322
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46242}
Bug: chromium:736758
Change-Id: If49fda42618c27be1472a98399e440ad26b7f199
Reviewed-on: https://chromium-review.googlesource.com/548401
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46241}
According to ES#sec-built-in-function-objects all built-in functions
must be strict.
This is a preliminary CL before changing the way we define built-in
functions in native JS files.
Bug: v8:6459
Change-Id: I8e60b342f04ea1b0843fe1990334cbb9b26ebac4
Reviewed-on: https://chromium-review.googlesource.com/546215
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46237}
Uninitialized property accesses are replaced with SOFT deopts in
TurboFan, but uninitialized JSCall nodes are not, and instead they
just stick around and are also not being inlined because the heurstic
in TurboFan doesn't consider those candidates since their call frequency
is below the threshold. This unifies the behavior and also replaces
uninitialized calls with SOFT deopts, addressing some inconsistency in
optimization behavior as discovered by Brian White of Node for example
here: https://twitter.com/mscdexdotexe/status/879005026202640385R=jarin@chromium.org
BUG=v8:4551, v8:5267
Review-Url: https://codereview.chromium.org/2956843002
Cr-Commit-Position: refs/heads/master@{#46231}
If a String object contains unicode, the returned {ToCString()} may
actually longer than the {length()} of the String.
But it's always null-terminated, so we can just print it without
explicitly passing a length.
R=ahaas@chromium.org
Change-Id: I3398f151d70ed459ecd8093ea18409670a7374c7
Reviewed-on: https://chromium-review.googlesource.com/548058
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46225}
The implication was actually in the wrong direction: If there is no
memory start address, then the size must be 0.
If the size is 0 though, we might allocate nevertheless to have guard
pages around the accessible memory.
R=ahaas@chromium.org
BUG=chromium:736584
Change-Id: I297dece658d5eaf69c58ecb109ff21d3ca0b8a8d
Reviewed-on: https://chromium-review.googlesource.com/548635
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46221}
Test that unicode identifiers can be used for imports and exports, and
that unicode function names appear correctly in error messages.
R=ahaas@chromium.org
Change-Id: Ic6ac77159c275845886b2eb779cf59edb8cba9ea
Reviewed-on: https://chromium-review.googlesource.com/548315
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46220}
This is a regression test that will ensure that follow-up CLs that will
touch native function definitions will not brake anything.
Bug: v8:6459
Change-Id: Iceafd38462f2d9de14e119b6aa48be2b9bff1d33
Reviewed-on: https://chromium-review.googlesource.com/545935
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46200}
This is a fix to https://codereview.chromium.org/2929853003 that got
reverted. The DCHECK checked to see that it was not in a background
thread. While this is a property we want for v8, it is also used
by blink, and blink violates this property.
Therefore, this CL removes the DCHECK for now.
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2961443002
Cr-Commit-Position: refs/heads/master@{#46190}
Move bytecode array writing logic into the array builder, allowing us to
remove the bytecode array writer and bytecode node, and convert runtime
operand writing to compile-time bytecode operand writing using the
information statically known at compile time.
Bug: v8:6474
Change-Id: I210cd9897fd41293745614e4a253c7c251dfffc9
Reviewed-on: https://chromium-review.googlesource.com/533055
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46183}
This prepares ground for switching mark-compactor to use
Worklist data-structure instead of the existing marking deque.
BUG=chromium:694255
Change-Id: I0ac4c563018a9619962fb4bf388b5f3cceffb86d
Reviewed-on: https://chromium-review.googlesource.com/544933
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46178}
The race happens when the layout descriptor is evacuated at the same
time as an object that has this layout descriptor is evacuated.
Change-Id: I0a5fc545cf359fdfe738d8b6359713f5ea170986
Reviewed-on: https://chromium-review.googlesource.com/544953
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46175}
This reverts commit 217d654c9b.
Reason for revert: Changes layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16520
Original change's description:
> [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
>
> Bug: v8:6425
> Change-Id: I528c5007de52215beba80851ab04693ecec038e2
> Reviewed-on: https://chromium-review.googlesource.com/543047
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46163}
TBR=marja@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org
Change-Id: I94543526f39f0a20452fbce1a7bc6744cac66621
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6425
Reviewed-on: https://chromium-review.googlesource.com/544993
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46171}
This removes the --turbo flag and solely relies on the filter pattern
provided via --turbo-filter when deciding whether to use TurboFan. Note
that disabling optimization wholesale can still be done with --no-opt,
which should be used in favor of --no-turbo everywhere.
Also note that this contains semantic changes to the TurboFan activation
criteria. We respect the filter pattern more stringently and no longer
activate TurboFan just because the source contains patterns forcing use
of Ignition via {AstNumberingVisitor::DisableFullCodegenAndCrankshaft}.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I0c855f6a62350eb62283a3431c8cc1baa750950e
Reviewed-on: https://chromium-review.googlesource.com/528121
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46167}
Async generator yield* is still desugared in the parser, to be moved to the BytecodeGenerator in a future CL.
Bug: v8:6472
Change-Id: I8b33e2f9e931949f7375540099cd8ec3a6b27cf1
Reviewed-on: https://chromium-review.googlesource.com/539335
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46165}
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
Bug: v8:6425
Change-Id: I528c5007de52215beba80851ab04693ecec038e2
Reviewed-on: https://chromium-review.googlesource.com/543047
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46163}
This piggy-backs on top of existing precise and best-effort coverage to expose
block coverage through the inspector protocol.
Coverage collection now implicitly reports block-granularity coverage when
available. A new 'isBlockCoverage' property on Inspector's FunctionCoverage
type specifies the granularity of reported coverage.
For now, only count-based block coverage is supported, but binary block
coverage should follow soon.
Support is still gated behind the --block-coverage flag.
Bug: v8:6000
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I9c4d64e1d2a098e66178b3a68dcee800de0081af
Reviewed-on: https://chromium-review.googlesource.com/532975
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46157}
HistoryTimer's can't run in the background because they use a timer
with a simple api of Start() and Stop(). This CL fixes this problem
by building a base class TimedHistogram that doesn't have a timer.
The class HistoryTimer is modified to use this base class so that
uses that run on the foreground thread do not need to be modified.
It also adds a new class TimedHistogramScope that defines the timer
in this class. This allows the corresopnding TimedHistogram class to
be type safe.
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2929853003
Cr-Commit-Position: refs/heads/master@{#46150}
In most cases, I'm using ENTER_V8 which is due to the fact that the
respective methods might end up executing script, either because they
invoke some callback, or because they might trigger a proxy trap.
Also add microtask suppression scopes in the debugger to all the places
that need one according to tests.
BUG=v8:5830
R=marja@chromium.org,jgruber@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I24cc3de37fc0d8156acfe86b290568e5f8f662b4
Reviewed-on: https://chromium-review.googlesource.com/519262
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46146}
This CL leverages and extends the deopt-to-stub mechanisms previously
introduced to support deopting from CSA-built builtins (e.g. Array.prototype.forEach).
BUG=v8:6373
LOG=N
Review-Url: https://codereview.chromium.org/2890363002
Cr-Commit-Position: refs/heads/master@{#46144}
If the fuzzer input cannot be executed in the interpreter within a step
limit, then the interpreter does not calculate the result but instead
finishes with a RangeError. The problem with the input of the bug report
was that the interpreter finished with that RangeError, but the
execution of the compiled code still returned a result, which was
naturally not a RangeError and therefore caused the result check to fail.
With this CL the compiled code is not even executed when there is a
RangeError after the execution in the interpreter. Thereby we also
avoid executing an infinite loop.
BUG=chromium:734435
R=clemensh@chromium.org
Change-Id: If9d0fb9e14e84f06d6f11d22f882363d56c1c20b
Reviewed-on: https://chromium-review.googlesource.com/544838
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46140}
In the failing case (see test), the loop variable (which should be context
allocated) is in a hidden scope, so we need to save and restore data for hidden
scopes too.
The !is_hidden() check was overly limiting - NeedsScopeData already handles the
"hidden leaf scope" case which is the one we want to avoid.
(Btw, this also means that the previous assumption "variables in hidden scopes
are not context allocated" was wrong.)
BUG=v8:5516
Change-Id: I1c6116654b19ef0cfd64e8a743b46af683a9fcd5
Reviewed-on: https://chromium-review.googlesource.com/544938
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46136}
let f = function g() { ... } declares "g" inside the function. This
CL makes the preparser declare it too, and saves + restores the scope data for
it.
BUG=v8:5516
Change-Id: Id4c64f446d30f5252038cfb0f0f473b85ba24a9b
Reviewed-on: https://chromium-review.googlesource.com/544816
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46133}
transition, check to see if we have already done this transition.
BUG=v8:6450
Review-Url: https://codereview.chromium.org/2915863004
Cr-Commit-Position: refs/heads/master@{#46129}
The test setup was as follows:
- Preparse function test() { ... }, get scope allocation data.
- Apply the scope allocation data to (function test() { ... })();
- Compare against normal scope allocation for (function test() { ... })();
But the IIFE is unnecessary - we already disable lazy parsing.
Cleaning this up is needed because in the next CL, I want to fix the Scopes
produced by PreParser in this case:
let f = function g() {
// Here we should declare g!
}
And that fix will make the variables in
function test() {
// Here we don't declare test
}
and
(function test() {
// Here we do declare test
})();
not match any more, so it doesn't make sense to compare them against each other.
BUG=v8:5516
Change-Id: I93d154c6977bb3cbe405b6ca193cf6283df297bc
Reviewed-on: https://chromium-review.googlesource.com/543341
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46128}
This switches all uses of the patching {BinaryOpICStub} over to the
respective existing and non-patching CSA-builtins, and removes some
supporting code. It also removes the inlined SMI handling.
R=verwaest@chromium.org
BUG=v8:6408
Change-Id: If547c0127bfcafbd01ccb33b702b1868006ebcb1
Reviewed-on: https://chromium-review.googlesource.com/541398
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46122}
This will allow for embedders to easily implement their own Platform
without duplicating the tracing controller code.
BUG=v8:6511
R=fmeawad@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I7c64933d12b2cf53f0636fbc87f6ad5d22019f5c
Reviewed-on: https://chromium-review.googlesource.com/543015
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Fadi Meawad <fmeawad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46118}
In edge cases such as the following, sloppy-mode block-scoped function
hoisting is expected to occur:
eval(`
with({a: 1}) {
function a() {}
}
`)
In this case, there should be the equivalent of a var declaration
outside of the eval, which gets set to the value of the local function
a when the body of the with is executed.
Previously, the way that var declarations are hoisted out of eval
meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL
assignment. However, such a lookup mode meant that the object in the
with scope received the assignment!
This patch fixes that error by marking the assignments produced by
the sloppy mode block scoped function hoisting desugaring so as to
generate a different runtime call which skips with scopes.
Bug: chromium:720247, v8:5135
Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748
Reviewed-on: https://chromium-review.googlesource.com/529230
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46116}
(Reland: NeedsManualRebaseline'd newly-fixed layout test in Chromium.)
This was never legal; the spec only allows '\0' in strict-mode strings
or templates when not followed by a decimal digit. Previously we were
only enforcing that it not be followed by an _octal_ digit.
This was already fixed for numeric literals, but not for escape
sequences in strings.
BUG=v8:6504
Review-Url: https://codereview.chromium.org/2948903002
Cr-Commit-Position: refs/heads/master@{#46106}
This method returns position of importing stmt in module source.
R=neis@chromium.org
Bug: chromium:721589
Change-Id: I8639796a001fdfec7cf5aa1bf1a27493f7a757a9
Reviewed-on: https://chromium-review.googlesource.com/541322
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46105}
Allows BitVector to resize, updating its own data and data length to
match the new length. We can fast-path resizes which fit into the same
data length (since high bits are already zero), and replace the pattern
where a BitVector is cloned using CopyFrom.
Change-Id: If79ca782c516e93b2a27c5e335e263554d522e88
Reviewed-on: https://chromium-review.googlesource.com/539522
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46101}
This CL improves reported source range precision in a couple of ways:
Source ranges are now standardized to consist of an inclusive start
index and an exclusive end index (similar to what's reported for
functions). For example:
0123456789 // Offset.
{ f(); } // Block represented as range {0,8}.
Duplicate singleton ranges (i.e. same start and end offsets) are now
merged (this only becomes relevant once jump statement coverage is
added). For example:
for (.) break; // Break- and loop continuation have same positions.
SourceRangeScope incorrectly collected starting position
(unconditionally) and end position (when no semi-colon was present).
01234567890123 // Offset.
for (.) break // Loop body range is {8,13}, was {6,9}.
Bug: v8:6000
Change-Id: I62e7c70cc894a20f318330a2fbbcedc47da2b5db
Reviewed-on: https://chromium-review.googlesource.com/541358
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46095}
Adds typed lowering of JSStringConcat to ConsString allocation if the
following conditions hold:
- All concatinations will result in a ConsString of >= ConString::kMinLength
- No concatinations will result in a empty string in the RHS unless there is
a sequential string in the LHS.
This also means JSStringConcat needs an eager checkpoint since it can
deopt if throwing a RangeError when the string length protector is valid.
BUG=v8:6243
Change-Id: I01ca79f884df467c10f2c032c72d51b5199c1a3c
Reviewed-on: https://chromium-review.googlesource.com/526636
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46093}
Add a new JSConstructWithArrayLike operator that is backed by the
ConstructWithArrayLike builtin (similar to what was done before
for the JSCallWithArrayLike operator), and use that operator to
optimize Reflect.construct inlining in TurboFan. This is handled
uniformly with JSConstructWithSpread in the JSCallReducer.
Also add missing test coverage for Reflect.construct in optimized
code, especially for some interesting corner cases.
R=petermarshall@chromium.org
BUG=v8:4587,v8:5269
Review-Url: https://codereview.chromium.org/2949813002
Cr-Commit-Position: refs/heads/master@{#46087}
- Iterator advancing is kept mainly unchanged.
- The iterator stores the size of the object which is to be used by the
caller in follow ups. This way we might be able to avoid further out
of line loads.
- The iteartor follows the regular std conventions allowing range based
loops.
Bug: chromium:651354
Change-Id: I8928224a62d3a48a48145a2d00279a28608bc634
Reviewed-on: https://chromium-review.googlesource.com/543335
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46085}
The fuzzer has already been removed from chromium. In addition I removed
code which was only used by this fuzzer.
BUG=chromium:734550
R=clemensh@chromium.orgCC=mstarzinger@chromium.org
Change-Id: I2ff4614e4d64131412ead759318e5c38e38f5d3d
Reviewed-on: https://chromium-review.googlesource.com/542816
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46078}
- Now that there are no boolean vector types, we can directly test the
results of relational ops.
Bug: v8:6020
Change-Id: Id2139133ae3a548a9985a26a3427cbeddc6272a6
Reviewed-on: https://chromium-review.googlesource.com/536176
Reviewed-by: Aseem Garg <aseemgarg@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46075}
On an error during {ProcessExports()}, we would just continue
execution, resulting in a DCHECK failure later.
I did not find any tests for exported globals, so I added a few
(including a regression test for the referenced bug).
R=ahaas@chromium.org
BUG=chromium:734295
Change-Id: I35370de934c274f870680c662ef848c72268a7bc
Reviewed-on: https://chromium-review.googlesource.com/539401
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46064}
If one wasm instance imports an exported function of another instance,
we unwrap the js-to-wasm wrapper of the export and use the underlying
code object directly. However, the code object does not keep the wasm
instance alive. It is only connected via a WeakCell.
With this CL, we explicitly store a FixedArray of all wasm instances
from which we imported functions to keep them alive at least as long as
the instance which imports the code.
R=mtrofin@chromium.org, ahaas@chromium.org
BUG=chromium:734345
Change-Id: I8dcfc9a4ea2d791a62d8cb7255039e481c50bdfd
Reviewed-on: https://chromium-review.googlesource.com/539738
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46062}
Inspector uses only BREAK_POSITION_ALIGNED, no tests pass STATEMENT_ALIGNED. It's exposed only with debugger API but I'm pretty sure that nobody actually uses it and as far as mirrors API is deprecated - it's time to remove it.
R=jgruber@chromium.org
Bug: none
Change-Id: I28d62e145811d3eb6f4d64007c47c51b2ecbaf0f
Reviewed-on: https://chromium-review.googlesource.com/536934
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46056}
This makes sure that the coercion of global import values to numbers
remains non-observable to JavaScript. It allows instantiation failures
to fall back to JavaScript proper without accidentally causing some
side-effect to happen twice. Also coercions might invalidate previous
checks done during linking or throw exceptions.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6431
BUG=v8:6431
Change-Id: Ibe2f7a336bc0fb25532d526746ecc802e04bbd5c
Reviewed-on: https://chromium-review.googlesource.com/512544
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46051}
The constructor of WireBytesRef checks that offset+length is still in
the uint32_t range. This CL avoids triggering this check on illegally
size strings.
R=ahaas@chromium.org
BUG=chromium:734246
Change-Id: Iab5c7013aa3e0ac5060bc4733e712a1652679b1a
Reviewed-on: https://chromium-review.googlesource.com/539402
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46050}
This was never legal; the spec only allows '\0' in strict-mode strings or templates
when not followed by a decimal digit. Previously we were only enforcing that it
not be followed by an _octal_ digit.
This was already fixed for numeric literals, but not for escape sequences in strings.
BUG=v8:6504
Review-Url: https://codereview.chromium.org/2950633002
Cr-Commit-Position: refs/heads/master@{#46046}
Add a new JSCallWithArrayLike operator that is backed by the
CallWithArrayLike builtin, and use that operator for both
Function.prototype.apply and Reflect.apply inlining. Also unify
the handling of JSCallWithArrayLike and JSCallWithSpread in
the JSCallReducer to reduce the copy&paste overhead.
Drive-by-fix: Add a lot of test coverage for Reflect.apply and
Function.prototype.apply in optimized code, especially for some
corner cases, which was missing so far.
BUG=v8:4587,v8:5269
R=petermarshall@chromium.org
Review-Url: https://codereview.chromium.org/2950773002
Cr-Commit-Position: refs/heads/master@{#46041}
We can remove a lot of native code and rely on CallOrConstructVarargs
to do the stack manipulation for us.
This will also take advantage of the fast-path for double arrays in
CallOrConstructDoubleVarargs.
We can also remove Runtime_SpreadIterableFixed because it isn't used
anymore. We just call directly into spread_iterable from CSA.
Bug: v8:6488, chromium:704966
Change-Id: I81a18281f062619851134fff7ce88471566ee3b5
Reviewed-on: https://chromium-review.googlesource.com/535615
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46038}
Previously, Date.toString() and friends were completely
implementation-defined. However, they actually seemed to match
each other's behavior with the exception of how years less than
1000 are formatted. The rough consensus among browsers seemed
to be %04d, so this was standardized at TC39 [1]. V8 previously
used %4d (it was the only one to do so); this patch adopts
the new standard.
[1] 5d4acf3377
Bug: v8:6076
Change-Id: I8c795a4e1b71187ad7c24a1aee8d7d66719a2586
Reviewed-on: https://chromium-review.googlesource.com/536733
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46037}
For each Managed<T> (which is a Foreign), we create a weak global handle
with a finalizer which deletes the referenced C++ object once the
Foreign is dead.
Before calling this finalizer, the garbage collector needs to mark the
referenced object black (i.e. live), because the finalizer might
resurrect it.
Since this is never done for managed objects, we can use the more
lightweight phantom handle semantics, which allows the referenced
object to be garbage collected right away.
However, we can't access the global handle via the WeakCallbackInfo,
because the global handle will already be garbage collected. So we need
to store it explicitly. This is solved by storing the global handle
together with the finalizer.
In order to implement this, ownership of the ManagedObjectFinalizer
is moved from the isolate to the managed object.
R=ulan@chromium.org, mtrofin@chromium.org
BUG=v8:6505, chromium:734345
Change-Id: I94a245df601f70e19355d82439d30099e159231b
Reviewed-on: https://chromium-review.googlesource.com/539578
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46036}
This test checks how much time we spent for generating Debugger.paused notification.
R=machenbach@chromium.org
Bug: chromium:688036
Change-Id: Ie8a52aafe6c8d93401b0b2a90a202ddff7de78ef
Reviewed-on: https://chromium-review.googlesource.com/538584
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46035}
The initial implementation did not work in certain cases.
For example, in the following case 'f' didn't have a shared name while
it should have had an empty shared name:
var f = (function() { return function() { return 42; } }();
The new implementation ensures that all anonymous functions have empty
shared name and if any of them happen to be an object literal property
value or an accessor function or a concise method then such a function
is marked as having no shared name.
Bug: v8:6459
Change-Id: I0f936afce0c152d91b2b41c1dc475a5ed841eca0
Reviewed-on: https://chromium-review.googlesource.com/538666
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46026}
Adds a 'performance' test which tracks the number of expressions
which can be nested before the compiler runs out of stack space.
This isn't really a performance test, but is created as a js-perf-test
to enable regression tracking in the dashboards.
Change-Id: Iee0c00df53b38b083e2dde09676ac9b13e439461
Reviewed-on: https://chromium-review.googlesource.com/539419
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46019}
- Use correct prefixes for SIMD/Atomics ops
- S128 LoadMem/StoreMem should not use 0xc0/0xc1 opcodes, these are now
being used for sign extension
- S128 LoadMem/StoreMem should use prefixed opcodes
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2943773002
Cr-Commit-Position: refs/heads/master@{#46016}
This patch updates the error positition and the error msg.
Previously,
→ ./out.gn/x64.release/d8 test.js
test.js:1: TypeError: undefined is not a function
var [a] = {};
^
TypeError: undefined is not a function
at test.js:1:1
With this patch,
→ ./out.gn/x64.release/d8 test.js
test.js:1: TypeError: [Symbol.iterator] is not a function
var [a] = {};
^
TypeError: [Symbol.iterator] is not a function
at test.js:1:11
Bug: v8:5532
Change-Id: Ib066e8ec8a53fdf06cce491bde4b1d0c6d564cbc
Reviewed-on: https://chromium-review.googlesource.com/539024
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46015}
We only need to use this for certain Intrinsics defined in the spec.
This CL removes unnecessary uses.
Bug: v8:6474
Change-Id: I13a9f0c57d877dd65a883a38f9683d55623030d3
Reviewed-on: https://chromium-review.googlesource.com/529224
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46012}
Track execution counts of the continuations of block structures (e.g.
IfStatements) to capture cases in which execution does not continue after a
block. For example:
for (;;) {
return;
}
// Never reached, tracked by continuation counter.
A continuation counter only has a start position; it's range is implicitly
until the next sibling range or the end of the parent range.
Bug: v8:6000
Change-Id: I8e8f1f5b140b64c86754b916e626eb50f0707d70
Reviewed-on: https://chromium-review.googlesource.com/530846
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46006}
If we pass in thin-string into a keyed load, the underlying internalized string is used to find the handler. However, the thin string itself was used to interpret the handler. Since the thin string itself isn't unique, this caused existing properties on the prototype chain to not be found in case of dictionary-mode prototypes.
Bug: chromium:731193
Change-Id: Ic98d3789ecf9175e17d9c898ab13231aad59efcc
Reviewed-on: https://chromium-review.googlesource.com/539596
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46005}
It might happen that we deprecate the map of previous sub-literals if we create
literals with the same map several times. This is usually the case for
configuration arrays.
Bug: chromium:734051
Change-Id: I82284e5aae632286135b2092816d776d229c65af
Reviewed-on: https://chromium-review.googlesource.com/538665
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46003}
Here we optimize Dsubu by instead of loading imm and subtracting, we
load -imm and perform addition when loading -imm takes less instructions
than loading imm. Similarily li is optimized by loading -imm and
performing addition or loading ~imm and inverting bits using nor when
one of these loads takes two instructions less than loading imm, saving
at least one instruction. Tests are adjusted to cover these
optimizations.
BUG=
TEST=cctest/test-assembler-mips/li_macro
cctest/test-assembler-mips/Dsubu
Review-Url: https://codereview.chromium.org/2909913002
Cr-Commit-Position: refs/heads/master@{#46001}
Large allocations would fail due to the flag not being set.
Bug: chromium:732836
Change-Id: I31686e382386a2d08582c86b29dc8f89841040d1
Reviewed-on: https://chromium-review.googlesource.com/535563
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45999}
For interpreted functions, use the optimized code slot in the feedback
vector to store an optimization marker (optimize/in optimization queue)
rather than changing the JSFunction's code object. Then, adapt the
self-healing mechanism to also dispatch based on this optimization
marker. Similarly, replace SFI marking with optimization marker checks
in CompileLazy.
This allows JSFunctions to share optimization information (replacing
shared function marking) without leaking this information across native
contexts. Non I+TF functions (asm.js or --no-turbo) use a
CheckOptimizationMarker shim which generalises the old
CompileOptimized/InOptimizationQueue builtins and also checks the same
optimization marker as CompileLazy and InterpreterEntryTrampoline.
This is a reland of https://chromium-review.googlesource.com/c/509716
Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
Reviewed-on: https://chromium-review.googlesource.com/535460
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45997}
Unify, simplify logic, reduce UTF8 specific handling.
Intend of this is also to have stream views.
Stream views can be used concurrently by multiple threads, but
only one thread may fetch new data from the underlying source.
This together with unified stream view creation is intended to be
used for parse tasks.
BUG=v8:6093
Change-Id: I83c6f1e6ad280c28da690da41c466dfcbb7915e6
Reviewed-on: https://chromium-review.googlesource.com/535474
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45994}
This CL also reduces the minimum semi-space size to 512K.
BUG=chromium:716032
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2942543002
Cr-Commit-Position: refs/heads/master@{#45992}
With the introduction of the fast-cloning double fields in the CSA stub for
literals we forgot to check for deprecated maps. As a result every subsequent
IC-miss would have to migrate the objects from such boilerplates.
This CL makes sure we don't use the deprecated map when copying boilerplates,
thus restoring the original behavior.
Bug: v8:6211 chromium:728682
Change-Id: If9ea1e0c5c6fb4236cb7a82ea33306a600925ac3
Reviewed-on: https://chromium-review.googlesource.com/538677
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45981}
Storing the boilerplate on the first run leads to memory ovehead for code
that is run only once. Hence we directly return the creating literal on the
first run and only start creating copies from the second run on.
Bug: v8:6211
Change-Id: I69b96d124a5b594b991fdbcc76dbf935d973ffad
Reviewed-on: https://chromium-review.googlesource.com/530688
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45975}
This removes the heuristic from {JSStackFrame::IsConstructor} that tried
to infer whether a frame was called as a constructor or not from the
receiver value. We are now carrying along the appropriate bit derived
from the frame type instead.
R=jgruber@chromium.org
TEST=message/regress/regress-5727
BUG=v8:5727
Change-Id: I0e2f1d0f95485c84c4ebcd3cbfe0123c6afd2e01
Reviewed-on: https://chromium-review.googlesource.com/500313
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45972}
This reverts commit 8196e10265.
Reason for revert: Performance regression due to hashcode lookup.
Original change's description:
> [builtins] Move most WeakMap/WeakSet code from JS to C++ builtins
>
> They were already implemented mostly in C++ (only error/negative
> cases were handled in script), so this is mostly just a cleanup.
> Only the constructors remain in script after this CL.
>
> Bug: v8:6354
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb
> Reviewed-on: https://chromium-review.googlesource.com/531670
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45924}
TBR=adamk@chromium.org,cbruni@chromium.org,gsathya@chromium.org
Bug: v8:6354, chromium:733238
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia5a741b9587886298f3ca057f6a6adeba556b8e0
Reviewed-on: https://chromium-review.googlesource.com/537207
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45966}
Previously, when destructuring against null or undefined we would
print:
d8> var { x } = null
(d8):1: TypeError: Cannot match against 'undefined' or 'null'.
var { x } = null
^
TypeError: Cannot match against 'undefined' or 'null'.
at (d8):1:1
The above message uses the term "match" which isn't a common term in
JavaScript to describe destructuring. This message also doesn't
provide the name of the property that fails destructuring.
This patch changes the error message to be:
d8> var { x } = null;
(d8):1: TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
var { x } = null;
^
TypeError: Cannot destructure property `x` of 'undefined' or 'null'.
at (d8):1:1
This patch changes the message to say "destructure" instead of "match".
This patch adds support for printing property names that are string
literals. We iterate through every property and pick the first string
literal property name if it exists. This provides at least some
feedback to the developer.
This patch also makes the pointer point to the position of the
property name that fails destructuring.
For computed and numeric property names, we print a generic error:
d8> var { 1: x } = null
(d8):1: TypeError: Cannot destructure against 'undefined' or 'null'.
var { 1: x } = null
^
TypeError: Cannot destructure against 'undefined' or 'null'.
at (d8):1:1
Bug: v8:6499
Change-Id: I35b1ac749489828686f042975294b9926e2dfc53
Reviewed-on: https://chromium-review.googlesource.com/537341
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45965}
I incorrectly assumed that ScopeIterator::SetModuleVariableValue gets called
when the frame is the module function.
R=jgruber@chromium.org, kozyatinskiy@chromium.org
Bug: v8:1569, v8:6484
Change-Id: I1fbad8ccde57280149547c78e679527f7a0c89dd
Reviewed-on: https://chromium-review.googlesource.com/535620
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45961}
Use ICU to check ID_Start, ID_Continue and WhiteSpace even for BMP
when V8_INTL_SUPPORT is on (which is default).
Change LineTerminator::Is() to check 4 code points from
ES#sec-line-terminators instead of using tables and Lookup function.
Remove Lowercase::Is(). It's not used anywhere.
Update webkit/{ToNumber,parseFloat}.js to have the correct expectation
for U+180E and the corresponding expected files. This is a follow-up to
an earlier change ( https://codereview.chromium.org/2720953003 ).
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg,v8_mac_dbg;master.tryserver.chromium.android:android_arm64_dbg_recipe
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng
BUG=v8:5370,v8:5155
TEST=unittests --gtest_filter=CharP*
TEST=webkit: ToNumber, parseFloat
TEST=test262: built-ins/Number/S9.3*, built-ins/parse{Int,Float}/S15*
TEST=test262: language/white-space/mong*
TEST=test262: built-ins/String/prototype/trim/u180e
TEST=mjsunit: whitespaces
Review-Url: https://codereview.chromium.org/2331303002
Cr-Commit-Position: refs/heads/master@{#45957}
This removes support for reconstructing stack frames for full-codegen
from the deoptimizer. We no longer deoptimize to such code. This also
allows us to remove the {DeoptimizationOutputData} data structure.
R=jarin@chromium.org
BUG=v8:6409
Change-Id: Id28ef05aa985b6877b5c91926a7d7d0d6d6e661d
Reviewed-on: https://chromium-review.googlesource.com/535537
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45943}
This removes the ability to prepare bailout points in code generated by
the {FullCodeGenerator}. Such code is no longer used as the target of
deoptimization attempts, hence storing deoptimization data is obsolete.
R=jarin@chromium.org
BUG=v8:6409
Change-Id: I3200182a6e88014ce953881fa0d1ac0bc65ee424
Reviewed-on: https://chromium-review.googlesource.com/533153
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45939}
For unknown Argument object Maps we have to expect that constants fields
are kept on the Map.
Bug: chromium:729597
Change-Id: I110f77455ce434a431c8de27d021b1a5deb86f30
Reviewed-on: https://chromium-review.googlesource.com/532900
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45935}
- Eliminates S32x4Shuffle, S16x8Shuffle opcodes. All shuffles are subsumed
by S8x16Shuffle. This aligns us with the latest WASM SIMD spec.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2923103003
Cr-Commit-Position: refs/heads/master@{#45929}
Port the baseline implementation of Object.prototype.isPrototypeOf to
the CodeStubAssembler, sharing the existing prototype chain lookup logic
with the instanceof / OrdinaryHasInstance implementation. Based on that,
do the same in TurboFan, introducing a new JSHasInPrototypeChain
operator, which encapsulates the central prototype chain walk logic.
This speeds up Object.prototype.isPrototypeOf by more than a factor of
four, so that the code
A.prototype.isPrototypeOf(a)
is now performance-wise on par with
a instanceof A
for the case where A is a regular constructor function and a is an
instance of A.
Since instanceof does more than just the fundamental prototype chain
lookup, it was discovered in Node core that O.p.isPrototypeOf would
be a more appropriate alternative for certain sanity checks, since
it's less vulnerable to monkey-patching. In addition, the Object
builtin would also avoid the performance-cliff associated with
instanceof (due to the Symbol.hasInstance hook), as for example hit
by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
The main blocker was the missing performance of isPrototypeOf, since
it was still a JS builtin backed by a runtime call.
This CL also adds more test coverage for the
Object.prototype.isPrototypeOf builtin, especially when called from
optimized code.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
BUG=v8:5269,v8:5989,v8:6483
R=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2934893002
Cr-Commit-Position: refs/heads/master@{#45925}
They were already implemented mostly in C++ (only error/negative
cases were handled in script), so this is mostly just a cleanup.
Only the constructors remain in script after this CL.
Bug: v8:6354
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb
Reviewed-on: https://chromium-review.googlesource.com/531670
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45924}
TracingCpuProfiler test updates the current plaform while
concurrent marking is running.
This patch also disables stress-incremental-marking for
mjsunit/regress-430201.
BUG=chromium:694255
Change-Id: I85ff538c47bce0300cde3204989ef3f9512b805f
Reviewed-on: https://chromium-review.googlesource.com/533873
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45921}
This patch also fixes several cctests that require manual GC.
BUG=chromium:694255
Change-Id: Ida93ed2498a6c5b0187ee78d2b1da27d2ff1906a
Reviewed-on: https://chromium-review.googlesource.com/533233
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45913}
The new fuzzer takes the fuzzer input as module bytes and compiles them
with WebAssembly asynchronous compilation.
R=mtrofin@chromium.org
Change-Id: I9740edec68e26c04d011d85c68521e340be13c4c
Reviewed-on: https://chromium-review.googlesource.com/506156
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45912}
The function that generated a pre-shifted immediate didn't account for the
instruction with post-shift being unencodable. Fix this by passing
information about the target instruction, and use it to limit the application
of pre-shift.
BUG=chromium:725858
Change-Id: Ia0f70b2ea057975d90162aa6889f15b553acd321
Review-Url: https://codereview.chromium.org/2922173004
Cr-Commit-Position: refs/heads/master@{#45911}
There exists a hidden assumption in V8 that neither foreground nor
background tasks own any memory. For asynchronous WebAssembly
compilation this assumption was wrong, which causes crashes when V8 shut
down before the compilation finished.
With this CL I change the way asynchrous compilation happens. In the
existing implementation each compilation stage provided its own task
which could be spawned either in foreground or background. With this CL
each stage only provides a state, and a generic CompileTask executes on
that state. There exists exactly one state at a time.
To have exactly one state at a time I combined the stages
ExecuteCompilationUnits and FinishCompilationUnits to a single stage. In
addition I removed the WaitForBackgroundTasks stage and added a
CancelableTaskManager to the AsyncCompileJob instead to do the waiting.
BUG=v8:6436
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I2eb61f74235c65524ce720c474eaf99ae7472c81
Reviewed-on: https://chromium-review.googlesource.com/532993
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45908}
This gives the embedder more context for deciding whether code
generation should be allowed or not, or they can chose to include the
code in a report.
BUG=chromium:732736
R=ahaas@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ibbaa3d0574319d290f15565be3eed2ee4d3dda36
Reviewed-on: https://chromium-review.googlesource.com/532875
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45905}
This reverts commit e39c9e020f.
Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561
Original change's description:
> [compiler] Drive optimizations with feedback vector
>
> For interpreted functions, use the optimized code slot in the feedback vector
> to store an optimization marker (optimize/in optimization queue) rather than
> changing the JSFunction's code object. Then, adapt the self-healing mechanism
> to also dispatch based on this optimization marker. Similarly, replace SFI
> marking with optimization marker checks in CompileLazy.
>
> This allows JSFunctions to share optimization information (replacing shared
> function marking) without leaking this information across native contexts. Non
> I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
> generalises the old CompileOptimized/InOptimizationQueue builtins and also
> checks the same optimization marker as CompileLazy and
> InterpreterEntryTrampoline.
>
> Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
> Reviewed-on: https://chromium-review.googlesource.com/509716
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45901}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
Reviewed-on: https://chromium-review.googlesource.com/532916
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45903}
For interpreted functions, use the optimized code slot in the feedback vector
to store an optimization marker (optimize/in optimization queue) rather than
changing the JSFunction's code object. Then, adapt the self-healing mechanism
to also dispatch based on this optimization marker. Similarly, replace SFI
marking with optimization marker checks in CompileLazy.
This allows JSFunctions to share optimization information (replacing shared
function marking) without leaking this information across native contexts. Non
I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
generalises the old CompileOptimized/InOptimizationQueue builtins and also
checks the same optimization marker as CompileLazy and
InterpreterEntryTrampoline.
Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
Reviewed-on: https://chromium-review.googlesource.com/509716
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45901}
These CL skips the tests the same way it is done on ARM.
Bug:
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I03b5b6cb2c69a4838c649ce7beee6283f3324e6d
Reviewed-on: https://chromium-review.googlesource.com/532876
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#45900}
Double element types were much slower than Smi/Object previously.
We can box each double in a HeapNumber and push them into a new
FixedArray to save going into the runtime.
Bug: v8:4826, chromium:704966
Change-Id: I7f15d0d636a52760daefed722265c696c1ebb13e
Reviewed-on: https://chromium-review.googlesource.com/531004
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45897}
With the deprecation of Crankshaft, it's no longer necessary for
FullCodeGen to keep track of its runtime profiler ticks on the code
object, and we can instead unify the behaviour of FCG and Ignition to
both increment the SFI counter instead.
Bug: v8:6408
Change-Id: Idcdd673aa39af06fe15a0fc14dfda2afafb5e417
Reviewed-on: https://chromium-review.googlesource.com/528117
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45892}
The AST-based graph builder is by now only used for asm.js code. This
change hard-codes this assumption into the compilation pipeline and
hence allows us to remove support pertaining to deoptimization from
optimized code that was not derived from bytecode.
R=jarin@chromium.org
BUG=v8:6409
Change-Id: I1138f16f663db5b9ee34e3110184067b8fcffc8b
Reviewed-on: https://chromium-review.googlesource.com/531026
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45887}
Once a buffer has been externalized, V8 is no longer responsible for managing
the memory. The fact that V8 was freeing was leading to double free errors once
Blink's GC got around to freeing the buffer too.
Bug: chromium:730171, chromium:731046
Change-Id: Ib18a7e37cafd51bce0c5a983d5cf8f3e64eb2c13
Reviewed-on: https://chromium-review.googlesource.com/530132
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45882}
This feature has been on by default without incident
since V8 5.8.
Bug: v8:5051
Change-Id: I1baf81922efd87e07448955147c50a5ba5a0aa42
Reviewed-on: https://chromium-review.googlesource.com/532214
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45881}
Avoid constructing zones and large zone objects when initializing
WasmCompilationUnit. The main reason we did that is so we can cache
the CEntryStub node, which requires a code object, obtainable only
on the main thread. We need that value, however, on background threads,
which is also where we need the aforementioned large objects. We only
need that for the WasmCompilationUnits being currently compiled, which
is a number proportional to the number of background threads provided
by the embedder. Specifically, one zone is needed only for the duration
of the background compilation, while the second zone needs to survive
past that, so the compilation results may be committed to the GC heap
as Code objects.
The problem with these large objects is that the first allocation
in a Zone is at minimum 8KB. We used to allocate 2 zones. For
modules with 200K functions, that means 3.2GB of memory pre-allocated
before any of it is actually needed.
This change attaches a Handle to the CEntryStub on the WasmCompilationUnits,
and delays zone creation to when needed. The change also adds a way to
cache CEntryStubs in a JSGraph from a given Code handle - limited to the
scenario needed by wasm (and removable once we get wasm off the GC heap,
which subsumes removing this dependency on CEntryStubs)
An additional constraint for this change is that we want it to be easily
back-mergeable to address chromium:723899.
For the wasm payload in question, collecting the max memory used by d8
using /usr/bin/time --format='(%Xtext+%Ddata %Mmax)', we get the
following numbers (in KB):
- unchanged: 3307480
- patch 1: 1807140 (45% reduction)
- patch 3: 1230320 (62% reduction from first)
- patch 5/6: 519368 (84% reduction from first)
Bug: chomium:732010, chromium:723899
Change-Id: I45b96792daf8a9c8dc47d45fb52da75945a41401
Reviewed-on: https://chromium-review.googlesource.com/530193
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45880}
- Remove commented out line
- Simulate full space properly, independently of flags set
Bug:
Change-Id: I6013caae43eb40dd568fbd872eb0ee78288c61bf
Reviewed-on: https://chromium-review.googlesource.com/531084
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45874}
Distinguish the compilation caches instead by the shape of the key (cow fixed
array map meaning eval or script cache). This allows us to remove the odd "key"
argument from Shrink, EnsureCapacity and Rehash.
Bug: v8:6474
Change-Id: Ibcad22813063c3a9050da13dc51359f5b59e1254
Reviewed-on: https://chromium-review.googlesource.com/531184
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45873}
This adds missing support for in-object properties within objects having
the {JSGeneratorObject} type to materialization during deoptimization.
For corner-cases where the implicit generator object is statically known
not to escape, object layout might still be arbitrarily complex.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-732169
BUG=chromium:732169,v8:6481
Change-Id: I32f373913d60af64981dc4ed66873cc8a1dbe872
Reviewed-on: https://chromium-review.googlesource.com/530230
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45870}
The fence ensures that the concurrent marker observes consistent state
of mark-bits for newly allocated objects.
The patch also moves Bitmap functions to cc file and removes non-atomic
versions of SetRange and ClearRange.
BUG=chromium:694255
Change-Id: I466bef654f3d4a21b7aaebdfd6d5a39ddb5f2a0a
Reviewed-on: https://chromium-review.googlesource.com/530367
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45868}
