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}
in order to find out if that is the failing CHECK in a chrome crash
report...
Bug: chromium:996819
Change-Id: Ifdebbc88b0525e61a5b3f83caa0ce4279a8efb75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774718
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63428}
This partially reverts commit 763f63fff6.
Reason for the revert is that the breaking at stack overflow does not
introduce improvement of usability, but rather exposes many issues
caused by the fact that V8 cannot perform a lot of functionality close
to the stack limit.
We keep the test, slightly modified, and use a better way to
detect stack overflow.
Bug: chromium:997469
Change-Id: I32bdf96767812b19f138310cc2dbd6a818fbf031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771792
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63426}
This fixes an invalid assumption when emitting code for matching '^'
(start of line) in multiline regexps and '\b', '\B' in general.
What we used to do: if the current trace's cp_offset (the offset from
the current position) was non-zero, we assumed that we were looking at
subject string index 1 or greater (i.e.: not at the start of the string
or before).
This is no longer valid since cp_offsets can now be negative.
This CL changes the logic to omit start- and bounds-checks only for
strictly positive cp_offsets, where the above assumption still holds.
Bug: chromium:996391
Change-Id: I79be4fc295c6f0b63e41c13d1e91fdd00f2f2b42
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771794
Commit-Queue: Erik Corry <erikcorry@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Erik Corry <erikcorry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63424}
Instead of fully reverting the CL that introduced the old-to-new
invalidated set, simply do not filter recorded slots yet.
Bug: v8:9454
Change-Id: I2b880f64f29e319056ad49e2284dca26eb8770f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773252
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63423}
The previous pseudo-smi storage scheme for caching call target
addresses in a struct without requiring a custom visitor only
works on uncompressed 64-bit platforms. This patch fixes other
platforms (natural or compressed 32-bit) by boxing the address
in a Foreign.
Change-Id: I3c182c1d9ccae4858cac2757fc3daa40d1520998
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771780
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63422}
Remove unnecessary call to Serialize.
Change a Handle cast to a Ref cast.
Add a CHECK to JSHeapBroker::SetFeedback that the source is valid.
Bug: v8:7790
Change-Id: I6a2f10d45456c6b128beff009016009457dc109c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773248
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63421}
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: I5c603680cf6dd295e9d11a4eba70785e6dc512ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773244
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@{#63420}
At the moment we only run the js-api spec tests of the core API on our
try bots. With the new staging process we want to introduce for
WebAssembly language features, see
https://docs.google.com/document/d/1hB8mpWmzmtaxZ8PuJEkAWLwFqXTjrw7mJ3Ge9W1dB4E,
we also want to run the js-api spec tests of proposals for which we
already staged the implementation. With this CL I do the following
changes:
1) The tools/wasm/update-wasm-spec-tests.sh now copies the js-api spec
tests of the main spec and of the proposals to test/wasm-js/tests,
and then uploads this directory to google cloud storage. The main
spec tests are in test/wasm-js/tests, the proposal tests are in
test/wasm-js/tests/proposals/PROPOSAL_NAME/.
2) Adjust the test-runner in test/wasm-js to run tests in
tests/* instead of data/test/js-api/*. Thereby it also runs the
proposal tests in test/wasm-js/tests/proposals/PROPOSAL_NAME/.
For the proposal tests, the test runner now also adds d8 flags.
3) Remove the dependency to https://github.com/WebAssembly/spec from
DEPS.
4) Cleanup .gitignore and wasm-js.status
5) Disable spec tests we don't pass with the new proposal.
R=tmrts@chromium.org
Bug: v8:9653
Change-Id: Ib3420871f17cb146d6cc7868f5613942a7f79d84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768372
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63419}
Launching nullish behind a flag resulted in a small performance
regression in the adwords parsing benchmark. From local tests, doing a
little manual PGO seemed to improve performance slightly.
Parse.duration on this benchmark dropped from 1,639.188 ms to 1,535.312 ms
Bug: chromium:997652
Change-Id: I537985793cdf310a0dda5a69ded9f0ea2c0a7fb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773098
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63417}
This writes 0 to all trimmed slots and thus ensures that the invariant
that all recorded slots in the trimmed area are valid, which will allow
us to simplify invalidated slots tracking.
Specifically:
1) Arrays are never inserted into the invalidated objects set.
2) The recorded slots outside an invalidated object are valid.
Bug: v8:9454
Change-Id: Ifbef3752d52b5b47f2b694bd2b6c0a4c122abb7a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771793
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63416}
Previously variations of #constructor can be parsed when they are
static. This patch throws early errors for them always.
Bug: v8:8330
Change-Id: I51ab9b83f713c70d0896c0e8cab3282ef9a105f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1770332
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63413}
