This should allow us to add other Windows-10 versions to pool:Chrome
without adversely affecting the V8 bots.
Bug: chromium:990885
Change-Id: I760eb6b1fc6f9fb91c9bacce692b21cbc044b261
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1778916
Auto-Submit: John Budorick <jbudorick@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63487}
This change provides a quick way to see string contents in postmortem
debugging sessions, without digging through a (possibly very large, in
the case of ConsString) tree of properties. As well as being convenient
for inspecting String objects, this functionality will also be necessary
for displaying property names on JSReceiver objects. In order to support
custom behaviors for specific classes, this change extends the existing
generated debug reader classes with a visitor pattern.
Bug: v8:9376
Change-Id: I70eab9ea4e74ca0fab39bf5998d6a602716a4202
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771939
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63485}
When changing the code coverage or type profiler modes, first ensure
there are source positions for all BytecodeArrays as regenerating the
source positions after toggling the mode will result in a bytecode
mismatch.
Bug: v8:9656, v8:8510
Change-Id: Ic6cf3afec1588f11e5ce5fcbea2fd13e4452e15f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774721
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63484}
Our current Freelist uses 47 categories. Because FreeListCategory is
about 26 bytes or so, this causes a non-neglieable overhead per
page. This CL divides by two the number of categories used.
Benchmark have shown that this should not increase old heap size. And
since less categories will be used, size of mallocated objects will be
smaller.
Furthermore,in both precise and fast modes, Scavenger time is lower
when using 24 Freelists rather than 47.
Bug: v8:9329
Change-Id: I81cca63a0ffd0aad5f9e009a176f401f2299493d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1778941
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63483}
Extend stress source positions to also ensure source positions for eagerly
compiled inner functions when lazily compiling the outer function.
BUG=v8:8510
Change-Id: I66d04beb789f13c15ed87cf10f606723c18f5d8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774725
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63482}
Currently string and preparse data trimming code creates filler object
without clearing the slots in the trimmed area. This currently works
because the slots are overwritten by filler/free space map.
This CL explicitly clears the slots and makes the code more robust.
Bug: v8:9454
Change-Id: I20ad8a210eb17932e46be5df4b42389955b5e5eb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1778023
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63481}
This CL adds a LocationReference specifically for slices to Torque. This allows us to safely reference arrays in objects and pass around such references. For an array of T-typed elements, referencing yields a Slice<T>. In addition, the traditional element access syntax ('o.array[i]') now internally produces a slice, indexes it at 'i' and dereferences the resulting HeapReference.
Bug: v8:7793
Change-Id: I4af58e4d2feac547c55a1f6f9350a6c510383df2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771782
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63479}
This reverts commit f6e08f43fc.
This patch doesn't allow thin/cons strings to be inlined as weak refs
to them are not supported by the GC.
Bug: v8:9616
Change-Id: I0407654bd9d20fe0182de4b8554e21ddbce8b28c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774720
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63478}
This is a reland of 1fba044154
Chromium expectation tests have been disabled, and will be enabled
Original change's description:
> [destructuring] Elide coercible check for simple keys
>
> Simple object destructuring, such as `let {a,b} = o`, is less efficient
> than the equivalent assignments `let a = o.a; let b = o.b`. This is
> because it does a nil check of `o` before the assignments. However, this
> nil check is not strictly necessary for simple (i.e. non-computed) names,
> as there will be an equivalent nil check on the first access to o in
> `o.a`. For computed names the computation is unfortunately obervable.
>
> So, we can elide the nil check when the first property (if any) of the
> destructuring target is a non-computed name. This messes a bit with our
> error messages, so we re-use the CallPrinter to also find destructuring
> assignment based errors, and fiddle with the error message there. As
> a side-effect, we also get out the object name in the AST, so we can
> output a slightly nicer error message.
>
> Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63453}
TBR=verwaest@chromium.org
Bug: chromium:999473
Change-Id: Ib0b2e4be433c50521ba1722e1c06b672bfefa405
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777702
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63477}
Generating custom previews can invoke user specified JavaScript (via the
`window.devtoolsFormatters` custom formatters feature). These custom
formatters were previously invoked in the main page context, even for
objects coming from other `<iframe>`s. Instead of using the main
renderer context, we should instead generate the custom preview in the
creation context of the object.
Bug: chromium:997925
Change-Id: Ia07915cff6680153b6727e68117ed565e60bc1c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776093
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63476}
E.g. make the setup of the ObjectRef hash table more explicit.
Tbr: jgruber@chromium.org
Bug: v8:7790
Change-Id: I58c03848e7da5c418ff2d6ae1e71b644278f406b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776089
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63475}
This patch implements the access of private accessors by loading the
referenced component from the AccessorPair associated with private
name variables. It also makes the error messages for invalid kind
of private accessor access more specific.
Bug: v8:8330
Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
Change-Id: I6d441cffb85f8d9cd0417ec9b6ae20f3e34ef418
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695205
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63474}
This reverts commit 62e168308c.
Reason for revert: it will be relanded after branch
Original change's description:
> Reland x5 [arraybuffer] Rearchitect backing store ownership
>
> This reverts commit 8fdb23873b.
>
> Original change's description:
> > "Reland x4 [arraybuffer] Rearchitect backing store ownership"
> >
> > This is a reland of bc33f5aeba
> >
> > Contributed by titzer@chromium.org
> >
> > Original change's description:
> > > [arraybuffer] Rearchitect backing store ownership
> > >
> > > This CL completely rearchitects the ownership of array buffer backing stores,
> > > consolidating ownership into a {BackingStore} C++ object that is tracked
> > > throughout V8 using unique_ptr and shared_ptr where appropriate.
> > >
> > > Overall, lifetime management is simpler and more explicit. The numerous
> > > ways that array buffers were initialized have been streamlined to one
> > > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > > and the construction and destruction of the BackingStore object itself
> > > handles the underlying page or embedder-allocated memory.
> > >
> > > The embedder API remains unchanged for now. We use the
> > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > > keep the backing store alive properly, even in the case of aliases
> > > from live heap objects. Thus the embedder has a lower chance of making
> > > a mistake. Long-term, we should move the embedder to a model where they
> > > manage backing stores using shared_ptr to an opaque backing store object.
> >
> > TBR=yangguo@chromium.org
> >
> > BUG=v8:9380,v8:9221,chromium:986318
> >
> > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63041}
>
> TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org
>
> Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63461}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: Id8f67a68ab398032eb2975b1b24ee125394d9c4b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776095
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63471}
This is only for turbofan and interpreter, and simd lowering for 64x2 is
not implemented yet.
Bug: v8:8460
Change-Id: I0d046cb39ff64936da772e0db9a86b88b1509ac2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769194
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63466}
This reverts commit 1fba044154.
Reason for revert: blocks V8 roll due to layout test failures caused by error message changes:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/347
Original change's description:
> [destructuring] Elide coercible check for simple keys
>
> Simple object destructuring, such as `let {a,b} = o`, is less efficient
> than the equivalent assignments `let a = o.a; let b = o.b`. This is
> because it does a nil check of `o` before the assignments. However, this
> nil check is not strictly necessary for simple (i.e. non-computed) names,
> as there will be an equivalent nil check on the first access to o in
> `o.a`. For computed names the computation is unfortunately obervable.
>
> So, we can elide the nil check when the first property (if any) of the
> destructuring target is a non-computed name. This messes a bit with our
> error messages, so we re-use the CallPrinter to also find destructuring
> assignment based errors, and fiddle with the error message there. As
> a side-effect, we also get out the object name in the AST, so we can
> output a slightly nicer error message.
>
> Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63453}
TBR=leszeks@chromium.org,verwaest@chromium.org
Change-Id: I74cf06ebd987e5b8bbe1831b0042c085edf37f5b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776994
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63465}
Allow querying whether an object is capable of holding information that
is relevant to the embedder in its embedder fields.
Bug: chromium:999262
Change-Id: Iced1a1cc78142481990d40d91d8e70e6e5518c5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773268
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63463}
Port 213504b9d7
Original Commit Message:
The code fields in a JSRegExp object now either contain irregexp
compiled code or a trampoline to the interpreter. This way the code
can be executed without explicitly checking if the regexp shall be
interpreted or executed natively.
In case of interpreted regexp the generated bytecode is now stored in
its own fields instead of the code fields for Latin1 and UC16
respectively.
The signatures of the jitted irregexp match and the regexp interpreter
have been equalized.
R=pthier@google.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I2b0b82e76a800408ced2e92e811ce5e8dac2cf0f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1775725
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63462}
This reverts commit 8fdb23873b.
Original change's description:
> "Reland x4 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> Contributed by titzer@chromium.org
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> TBR=yangguo@chromium.org
>
> BUG=v8:9380,v8:9221,chromium:986318
>
> Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63041}
TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org
Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63461}
Port f72c844aa7
Original Commit Message:
Port f5ab7d38be
Port 65f3861e3b
Original Commit Message:
In a new test suite: "wasm-api-tests", using a new binary "wasm_api_tests",
powered by gtest/gmock (like unittests).
Also fix a bunch of issues that these tests uncovered, mostly to ensure
that the stack is walkable.
R=miladfar@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I565fba1a2437eb49be0c5247740f3fcac7b071db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1775723
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63460}
Before this CL the main thread fetched the background GC stats and
added them to the main runtime-call-stats table. This resulted
in background GC stats showing up in the main thread trace.
This CL switches the background GC stats to use worker thread runtime-
calls-stats table. This is now consistent with other background
components of V8 suchs background compiler and parser.
Bug: v8:9508
Change-Id: Ic4c0685ded6024f78d0f22f81419fd5677202f25
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776083
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63459}
This patch is mostly mechanical. A few changes in
implementation-visitor.cc might be worth mentioning:
- Don't generate both field offset macros and class definitions for the
same class. This was mostly just to keep me from forgetting to remove
the DEFINE_FIELD_OFFSET_CONSTANTS part when converting classes, but
also helpfully flagged that FixedArrayBase wasn't using the generated
class that it requested.
- Generate forward declarations for all tq-defined classes in
internal-class-definitions-tq.h. This is helpful for making things
compile when classes have fields of other class types.
- When generating accessors for union types, use the nearest class type
that contains the entire union rather than plain Object. This is
important for compile-time type safety. It also required a few minor
fixes elsewhere (isolate.cc, modules.cc, scope-info.cc,
source-text-module.cc, and a correction of the field types in
CallHandlerInfo to match how they're set in api.cc).
Change-Id: I3b9280e30779ce57fb9f3629eecfec898e26d708
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774976
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63458}
The code fields in a JSRegExp object now either contain irregexp
compiled code or a trampoline to the interpreter. This way the code
can be executed without explicitly checking if the regexp shall be
interpreted or executed natively.
In case of interpreted regexp the generated bytecode is now stored in
its own fields instead of the code fields for Latin1 and UC16
respectively.
The signatures of the jitted irregexp match and the regexp interpreter
have been equalized.
Bug: v8:9516
Change-Id: I30e3d86f4702a902d3387bccc1ee91dea501fe4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762513
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63457}
Since this produces a few false positives, also implemented a whitelist
mechanism to not report them.
Also, add a couple of tests and implemented automated testing against
test-expectations file.
Bug: v8:9321
Change-Id: I2915a29fe1891e8bbc51118bbd95ae072c8de023
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773243
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63456}
Sloppy eval extends the outer declaration scope's context. This is also
true for sloppy eval inside of other sloppy evals -- the outer declaration
scope's context is extended rather than the outer sloppy eval's
declaration scope. However, we consider eval scopes to also be declaration
scopes, for the purposes of strict eval and caching lookup variables. So,
we need to make sure that we skip through sloppy eval scopes when marking
a scope as calls_sloppy_eval.
In fact, we implement this rather as never marking sloppy eval scopes as
calls_sloppy_eval, under the assumption that the parent scope will already
have been marked calls_sloppy_eval by the outer eval.
As a drive-by, fix a TODO to move this logic from calls_sloppy_eval() to
RecordEvalCall(), rename the variable to something more meaningful, and
make Snapshotting to use a new calls_eval bit on Scope.
Bug: chromium:996751
Change-Id: I27ccc7ef429a7ce60b3bb02bf64a3820ae4a2c36
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773247
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63455}
This reverts commit a5d279da00.
Reason for revert: Causing failures in UBSAN Linux
See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/7672
Original change's description:
> [wasm-c-api][test] Run Wasm C API tests on bots
>
> by including them in the "bot_default" and "default" test sets.
> The build targets are already up to date, only the test runner
> needs to be updated.
>
> Change-Id: I06a4a35a8d00c25ab56874d8eb365418841a02ac
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768370
> Commit-Queue: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63436}
TBR=jkummerow@chromium.org,tmrts@chromium.org
Change-Id: I5b78e45eeae11ce460d2cdecba4e3cf8eacdb4f8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1775927
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63454}
Simple object destructuring, such as `let {a,b} = o`, is less efficient
than the equivalent assignments `let a = o.a; let b = o.b`. This is
because it does a nil check of `o` before the assignments. However, this
nil check is not strictly necessary for simple (i.e. non-computed) names,
as there will be an equivalent nil check on the first access to o in
`o.a`. For computed names the computation is unfortunately obervable.
So, we can elide the nil check when the first property (if any) of the
destructuring target is a non-computed name. This messes a bit with our
error messages, so we re-use the CallPrinter to also find destructuring
assignment based errors, and fiddle with the error message there. As
a side-effect, we also get out the object name in the AST, so we can
output a slightly nicer error message.
Change-Id: Iafa858e27ed771a146cd3ba57903cc73bb46951d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773254
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63453}
Port 2e0bc516b7
Original Commit Message:
Similar to CheckNotAtStart, one can now apply an offset to the
CheckAtStart operation. Due to a recent change, all callsites of
CheckNotAtStart now need to pass an offset, whereas previously the
offset was just assumed to be zero.
R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: I255ed27bd0d5bccfb9851696ca25f2bb4a984981
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1775721
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63452}
The maximal unoptimized frame size is calculated during instruction
selection and will be needed during code generation (it will be
applied as an offset to the stack check). Pass the information along
to the code generator through PipelineData.
Bug: v8:9534
Change-Id: Ia72cd70d57c3de2db9fe43d91b9378d8e2ab8a0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762302
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63451}
Adds a simple static class to manage fast path protectors, thereby
eventually allowing us to remove a bunch of boilerplate from isolate.
Bug: v8:9463
Change-Id: I99306e5c914c16045d0b891bdc3c62cfd98fddfc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774187
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63450}
TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
compile time including off-thread, while improving Octane scores by ~2%.
How things used to work:
There is a flag FLAG_min_inlining_frequency that limits inlining by
the callsite being sufficiently frequently executed. This call frequency
was measured relative to invocations of the parent (= the function we
originally optimize). At the same time, the limit was very low (0.15),
meaning we mostly relied on the total amount of inlined code
(FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.
How things work now:
Instead of measuring call frequency relative to parent invocations, we
should have a measure that predicts how often the callsite in question
will be executed in the future. An obvious attempt at that would be to
measure how often the callsite was executed in absolute numbers in the
past. But depending on how fast feedback stabilizes, it can take more
or less time until we optimize a function. If we just take the absolute
call frequency up to the point in time when we optimize, we would
inline more for functions that stabilize slowly, which doesn't make
sense. So instead, we measure absolute call count per KB of executed
bytecodes of the parent function.
Since inlining big functions is more expensive, this threshold is
additionally scaled linearly with the bytecode-size of the inlinee.
The resulting formula is:
call_frequency >
FLAG_min_inlining_frequency *
(bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
(FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)
The new threshold is chosen in a way that it effectively limits
inlining, which allows us to increase
FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
in general.
The reduction in compile time (x64 build) of ~10% was observed in Octane,
ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
The hope is that this will reduce CPU-time in real-world situations
too.
The Octane improvements come from inlining more in places where it
matters.
Bug: v8:6682
Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63449}
A recent CL (1762292 and 1765533) changed the FreeList strategy,
switching to one that uses 46 categories rather than the previous 6 we
had. This caused a reduction of V8's heap size by about 1-2% on
average. However, because FreeListCategory is 56 bytes, rather than 4
bytes as one might expect (2 bytes offset, 1 byte for the category
type, and 1 byte padding), the overall memory improvement is actually
lower than that.
For instance, when 256M memory is allocated,
1000 pages * 46 freelists * 56 bytes = 2.5M overhead
(ie, 1% overhead)
Ideally, FreeListCategory should only by 4 bytes: 2 bytes for the
offset of the top() on the page, 1 byte for the category type, and
1 byte padding.
This CL reduces the size of FreeListCategory by 24 bytes by removing
some fields.
More work should be done to reduce the size even further:
- Remove the available_ counter (this require maintaining byte count
at the page level rather than in each FreeListCategory; and
maintaining that counter is not trivial, but doable).
- Use a 16 bits offset to store the top() rather than a pointer.
- Get rid of prev_ and next_: this change is the most
complicated. It requires storing the space's pages in order, such
that when one page's freelist is empty, we move on to the next
page in the space.
- the type_ field might even be removable, since this information can
be deduced from the FreeListCategory's position in the page's array
or FreeListCategory.
Bug: v8:9329
Change-Id: I8fd72cfa31ca12ba0dbf10be3948a72caee15b57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773270
Commit-Queue: Darius Mercadier <dmercadier@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63448}
Doing some refactoring to perfetto build files. Rolling to
ensure that we are not breaking embedders in the process.
Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng
Bug: v8:8339
Change-Id: I88ab30cc809779e36aa7e5c141e8180cd239edae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773274
Auto-Submit: Primiano Tucci <primiano@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63446}
... to let C++ compiler know that isolate root is 4Gb aligned and give
it a chance to generate a better code.
Bug: v8:9353
Change-Id: Ibd23c14cc44107c722a446a84dd14ca66f3bccfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776079
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63445}
Similar to CheckNotAtStart, one can now apply an offset to the
CheckAtStart operation. Due to a recent change, all callsites of
CheckNotAtStart now need to pass an offset, whereas previously the
offset was just assumed to be zero.
Bug: chromium:996391
Change-Id: Ia59a584e93e5384479f05abddef7859b420b023a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773272
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63444}
The helper would cause the stack to be unaligned during pushes which caused issues
on Arm64. PushMultipleTimes is only used once by InterpreterEntryTrampoline,
therefore it doesn't make sense to change it's behaviour for --optimize-for-size.
Change-Id: I3bc7d39bc38ffd22a3ee6cca1cdafe5d656d77b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773275
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63443}
Printing regexp code used to behind the generic --print-code flag, but
there was no way to distinguish between irregexp-generated code; and
printing regexp bytecode was not supported at all (the
--trace-regexp-bytecodes flag *did* exist, but prints the execution
trace at runtime and not the generated bytecode sequence).
This CL adds two new flags:
--print-regexp-code
--print-regexp-bytecode
Regexp code is no longer printed as part of --print-code.
Example output for --print-regexp-bytecode:
generated bytecode for regexp pattern: .(?<!^.)
0x1ddcc614cbd0 0 PUSH_BT, 02, 00, 00, 00, c0, 00, 00, 00 .......
0x1ddcc614cbd8 8 LOAD_CURRENT_CHAR, 11, 00, 00, 00, b0, 00, 00, 00 .......
0x1ddcc614cbe0 10 CHECK_CHAR, 18, 0a, 00, 00, b0, 00, 00, 00 .......
0x1ddcc614cbe8 18 CHECK_CHAR, 18, 0d, 00, 00, b0, 00, 00, 00 .......
0x1ddcc614cbf0 20 PUSH_CP, 01, 00, 00, 00 ...
Bug: chromium:996391
Change-Id: I731defbd7cf9ed29753a39bb1d7205dc136ca950
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773249
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63442}
Fix tier-up issue where we would continue to execute bytecode instead of
tiering-up on x64. The problem was that the smi value is stored in upper
32 bits which would get truncated, so we were checking the wrong value.
Change-Id: I609b56ad58621c6ab7642d0ce453563ce09ae097
Bug: v8:9566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773269
Commit-Queue: Ana Pesko <anapesko@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63440}
