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}
Provide copy ctor and assignment operators as it turned out that they are
useful for embedders in certain scenarios when dealing with TracedGlobal
handles without finalization callbacks.
Bug: v8:9660
Change-Id: I2b04f540baeef61a0bc8329ca06b999571cbfe66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773250
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63439}
This extends --trace-block-coverage to output not only all raw coverage
slots, but also a detailed trace of all information that is generated by
coverage collection (i.e. after filtering and transforming collected
counts and ranges).
Example output:
Coverage for function='GetCoverage', SFI=0x3d23ea6dfb59,
has_nonempty_source_range=1, function_is_relevant=1
{start: 278, end: 441, count: 1}
{start: 357, end: 440, count: 0}
Bug: v8:6000,v8:9212
Change-Id: Ide09eb40999541df97409d0682a505ee0070b3a6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771777
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63437}
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}
Command descriptions:
!handles: print stats for handles or list them;
!jo_prev, !jo_next, !jo_in_ range: print managed objects near the given address;
!jo_in_range: print managed objects in the given range;
!jot: print the tree of referenced objects, starting from a given root;
!dp: 'dp'-like command, augmented with data about the managed pointers.
Change-Id: Ic72dd52ee8c68bc559f37ae04870d4e63ae0d554
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1772694
Commit-Queue: Irina Yatsenko <irinayat@microsoft.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63435}
This CL try to use a phi as a branch condition if the control flow from the
branch is known from previous conditions. This change will open up more branch
folding opportunities for later pass.
Change-Id: I26316ab3a68c2d58d0df53691981288a996d4ba1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674484
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63434}
Currently the backing store and elements kind might not aligned aka
backing store can be dictionary where elements kind is frozen/sealed
element kinds or the other way around. The reason is that
Object.preventExtensions change elements kind to DICTIONARY while
Object.seal/freeze change elements kind to SEALED/FROZEN element kind.
Apply both these operations can lead to that problem as in
chromium:992914
To solve this issue, we avoid Object.preventExtensions to change backing
store to dictionary by introducing new nonextensible elements kind.
These new nonextensible elements kind are handled similar to frozen,
sealed element kinds. This change not only fixes the problem but also
optimize the performance of nonextensible objects.
Change-Id: Iffc7f14eb48223c11abf3c577f305d2d072eb65b
Bug: chromium:992914, v8:6831
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760976
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63432}
This change allows the KeyAccumulator to throw a range error if there
are too many properties to be enumerated.
This CL introduces extensive checks during key enumeration in the run-time,
and might introduce regressions. If so, feel free to revert.
Bug: chromium:918301
Change-Id: I6166c0b15f1a05eac7116a979f12ba4833d1d1b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545902
Auto-Submit: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63430}
