This reduces the number of label indices accepted by {br_table} from the
full function body size to specifically 65520 labels. Note that TurboFan
already had a similar limitation on switches, but caused a crash during
compilation up until now. This change just makes the limit explicit and
avoids the crash during compilation.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-9759
BUG=v8:9759
Change-Id: I3a9a4406b19a7f98fc36707b3b946be846170a15
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1821457
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Backes [né Hammacher] <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63944}
This fixes how arguments of a call to {fround} are being parsed. It now
accepts a single "AssignmentExpression" only instead of an "Expression"
which could potentially be a whole comma-separated list of expressions.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-1006592
BUG=chromium:1006592
Change-Id: Ifaf0c2b048e4ec18429cc6039c0e7dcdecc1d0bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1815255
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63926}
This loads the call builtin from the Isolate root instead of embedding
it into the instruction stream. This can be more efficient, but more
importantly it fixes an issue with tracing and eventually allows for
background compilation of these wrappers.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-crbug-1006631
BUG=chromium:1006631
Change-Id: Ife1bc513340d233a3c01789c7b56126fe3b87f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1815245
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63924}
Change Parser::AllowsLazyParsingWithoutUnresolvedVariables to return
false if it may be parsing an arrow function.
Bug: v8:9758, v8:8510
Change-Id: Ic5d213d4358ff954a169c03e449197c3f050880c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1816510
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63920}
This cl adds support for top level await to d8, but still
does not allow top level await through parsing.
Unfortunately, due to that restriction this cl has no automated
tests, but I added a 'top-level-await' variant and manually
confirmed it passes locally.
Bug: v8:9344
Change-Id: I3528442768107f5ad1ed1e9e947cfceae91c0cc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808483
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63909}
The predictable platform can make tasks deadlock if the spawning task
is holding a lock that the spawn task also wants to take. This is
because the spawned task is just executed immediately within the
"context" of the spawning task.
The wasm async compile tests deadlock because the
{BackgroundCompileTask}s hold the shared {BackgroundCompileToken}
(reader lock) while spawning new tasks via {OnBackgroundTaskStopped} ->
{RestartBackgroundTasks}. The new tasks might want to cancel
compilation via {BackgroundCompileToken::Cancel}, which takes the
writer lock and hence deadlocks.
This can not happen on any other platform, since tasks are not nested
that way.
R=ahaas@chromium.org
Bug: v8:9760
No-Try: true
Change-Id: I9fc34d5de386aa5c6fdd64a1570fddcff872ec95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1816502
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63904}
With --wasm-far-jump-table, it will be possible to create 10k (and
more) modules in one process. So far, we hit the virtual address space
limit around 1k modules, because each module makes a reservation of
{kMaxWasmCodeMemory} upfront. After this change, each module will only
reserve the estimated needed code size (if --wasm-far-jump-table is
set).
The test is carefully optimized to not execute too much code in the
loop, so it can still run in simulators in reasonable time. Note that
the time for actually compiling the module is spent in C++, which is
fast in simulator builds.
R=mstarzinger@chromium.org
Bug: v8:9477, v8:9651
Change-Id: If74a825d272a65b82ca5433cb648b6a2271872e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1811038
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63903}
This adds an additional V8 API to get the backing store of an array
buffer. Unlike the existing API, the backing store comes wrapped
in a std::shared_ptr, making lifetime management with the embedder
explicit. This obviates the need for the old GetContents() and
Externalize() APIs, which will be deprecated in a future CL.
Contributed by titzer@chromium.org
Bug: v8:9380
Change-Id: I8a87f5dc141dab684693fe536b636e33f6e45173
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807354
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63883}
ArrayBuffer tracking has landed, turning on GrowMemory for Shared
WebAssembly.memory on by default. Enable all variants of tests based
on the new implementation.
Bug: v8:8564, v8:9221, v8:8832
Change-Id: I0ff8688636303896450b788b2ff5a7268d386050
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1808106
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63855}
The element segment encoding in the bulk memory proposal changed
recently. With this CL the V8 implementation gets up to date again.
R=thibaudm@chromium.org
Bug: v8:9658
Change-Id: I4f45d04369400356a6f3aaed9570c7870f5f97bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1778022
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63836}
Adding a %SimulateNewspaceFull runtime function speeds up this test
from 7m21s to 0.3s (on arm.optdebug with --jitless).
Bonus content:
- speed up mjsunit/md5 by 23x (5m25s -> 7.5s)
- speed up mjsunit/string-replace-gc by 8x (1m37s -> 12s)
Bug: v8:9700, v8:9396
Change-Id: Id00d0b83b51192edf1d5493b49b79b5d76e78087
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807355
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63829}
We used to have two special cases for named accesses on the global
proxy, one based on seeing the global proxy constant in the graph and
on based on seeing the global proxy map either in the feedback or in
the graph. A change I made a while ago accidentally disabled the second
one. This CL restores that.
Moreover, given how things are set up now (this might have been
different before), the first optimization is subsumed by the second
one, so this CL also removes the first one.
Finally, this CL records an accumulator hint in the case of a load,
which improves precision of the serializer for concurrent inlining.
Tbr: tebbi@chromium.org
Bug: v8:7790
Change-Id: I255afc6c79e5c5c900b3ccfcd8459d836d21e42b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1801954
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63806}
This randomizes new memory allocations and reservations. It's currently
used to test far jump tables in wasm better, but might be helpful
generally for testing arbitrary virtual memory layouts.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ie60b7c6dd3c4cd0f3b9eb8e2172912e0851c357d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803340
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63802}
This CL adds a flag to reduce the initial code space reservation size
(--wasm-max-initial-code-space-reservation), and adds a test which creates at
least four separate code spaces and calls between them.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: I1b4c430266962eb94dbe4b381f46b03c2ec07fc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782999
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63797}
Changes the Array(Includes|IndexOf)(Holey|Packed)Doubles builtins to
first check the input array is not empty before attempting to cast it to
a FixedDoubleArray as an empty array of doubles can be backed by a
FixedArray.
Bug: chromium:1004061
Change-Id: I12f302afa9596fb8a5581849662cd67fcc06f92b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1806676
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63794}
The current JSObject type is too specific as it can also be passed proxy
objects.
BUG=chromium:1003919,v8:6949
Change-Id: I2766868543827fc5ee6f99f3b120c7ffe9cfed39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803651
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63787}
This reimplements the "--time" option of run-tests.py to print the
20 slowest tests, on top of json_test_results infrastructure just
like the bots do it.
Additionally this CL speeds up a bunch of slow tests.
Bug: v8:9396
Change-Id: I40797d2c8c3bfdd310b72f15cd1a035844b7c6f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803635
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63786}
This reverts commit 9ce6792630.
Reason for revert: This was never intended to stay.
Original change's description:
> [turbofan] temporarily disable const-based load elimination
>
> This is a safe to merge hot-fix to tackle https://crbug.com/983764.
> To be reverted after merging to M77.
>
> Bug: chromium:983764
> Change-Id: I3cd27481f224b352ef6bcf9dde21a8f77616acff
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1786285
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63570}
TBR=tebbi@chromium.org,mslekova@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:983764
Change-Id: I9c07eab384818aaeecab0224cec0f6b5310e9e09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1801839
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63743}
The point of this test is to check for OOB access traps, the read/write
of the entire backing buffer is not useful to this test, and causes the
test to be really slow, especially on arm simulator. This change cuts
the runtime of the test from ~7.5min to ~1.5min.
Bug: v8:7783
Bug: v8:9396
Change-Id: Id57648e920b7631d8c481d2a43ded1c16cd2d1d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1793905
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63726}
Case statements have a list of statements associated with them, but are
not blocks, and were hence not fixed-up correctly for code coverage.
This CL also applies the fix-up to the "body" of case statements,
in this way removing ranges reported as uncovered between the final
break/return in a case and the next case (or end of function).
Drive-by: Add optional pretty printing to code coverage test results.
Change-Id: I5f4002d4e17b7253ed516d99f7c389ab2264be10
Bug: v8:9705
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1798426
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63719}
This fixes the case where a table entry contains a function constructed
via {WebAssembly.Function} and is then read out via a runtime function
from the table.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-crbug-1002388
BUG=chromium:1002388
Change-Id: Ic0a9a544baaf37e68cd22eb91f2ef0bdf5fa5842
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795352
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63709}
Current GetIterator bytecode loads and calls @@iterator property on a
given object. This change extends the bytecode functionality to check
whether the value returned after calling @@iterator property is a valid
JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the
returned value is not a valid JSReceiver. This change absorbs the
functionality of additional two bytecodes - JumpIfJSReceiver and
CallRuntime, that are part of the iterator protocol in the GetIterator
bytecode.
Bug: v8:9489
Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#63704}
This reduces the runtime from ~20m to ~2m (very unscientific measure
based on running the entire asm-wasm-i32 test with and without this
change).
I removed most of the constants that looked uninteresting, e.g. testing
for 10, 20, 30, isn't that interesting. The edge cases are left
untouched, min/max signed positive/negative ints and +/- 1 from both.
Bug: v8:7783
Bug: v8:9396
Change-Id: Ice363fc3f786dd55ff118ffa42f9ecea07880338
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1791632
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63695}
This adds a new API function and provides a simple implementation
of performance.measureMemory() in d8. The implementation currently
immediately resolves the result promise with the current heap size.
Bug: chromium:973627
Change-Id: Ia8e1963a49b7df628b5487a2c0d601473f0cb039
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796502
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63694}
This speeds up the check by ~10x.
This was tested by writing a simple test that compares a for-loop and
array.every():
for (var i = 0; i < kMemSize; i++) {
assertEquals(0, array[i]);
}
assertTrue(array.every((e => e == 0)));
The for-loop takes ~180s, every() takes ~19s.
Numbers above are for arm.debug build (simulator). On x64.debug builds
we can see a similar 10x improvement, from ~6s to ~400ms.
Bug: v8:7783
Bug: v8:9396
Change-Id: I83d46c7ec4a634612032c1d79585339cadb8b641
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1793904
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63691}
Change-Id: Ie0bd818c629bed3011212fb7c8ab81202a462501
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1798424
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63678}
This patch uses a bit in the Variable bit fields to distinguish
static private names from instance private names, so that we
can check the conflicts of private accessors that are complementary
but with different staticness in the parser, and use this
information later when generating code for checking static brands
for private method access.
Design doc: https://docs.google.com/document/d/1rgGRw5RdzaRrM-GrIMhsn-DLULtADV2dmIdh_iIZxlc/edit
Bug: v8:8330
Change-Id: I8d70600e594e3d07f77ea519751b7ca2e0de87b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781010
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63677}
Do not assume that the MaybeHandle that is returned when fetching for a property
is valid and instead check for its contents. Treat an empty handle as not
finding the right property.
Bug: chromium:1002827
Change-Id: Iac158086ec5f66cd9602f4a73ae78de367dd3e77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1796556
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63672}
After https://crrev.com/c/1793065 the test should be fast enough to
execute it everywhere.
R=mslekova@chromium.org
Bug: v8:9696, v8:7783
Change-Id: I2485d703d6e973217eddde2f2814e31f7fcd8a61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795343
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63647}
We don't handle all cases for stores to typed arrays in the builtins
related to storing a property. Bailout to runtime when storing into
a typed array if the property is not found on the object.
Bug: chromium:996161
Change-Id: I684c7c4f526b15cdfb5bfe3fd23218910486a59e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789396
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63639}
When analyzing functions scopes with the script_scope as parent, don't
skip migrating unresolved variables upwards if we could still be inside
an arrow head, which means accesses to those variables will be
correctly context allocated.
Bug: v8:8510, chromium:1000094
Change-Id: I684f2f8bc692de420203990f93e5c943b5b769c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789705
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63635}
It looks like the loop is there to create objects and trigger GC. It's
also tailored to Crankshaft, which was removed long ago.
This code currently times out on some arm bots, and it's hard to see
any value in it. Thus remove it.
R=mslekova@chromium.org
Change-Id: Ia47d4f70d679f79cfea523f467ff7adc3360cf6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1793065
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63630}
This CL implements the tier-up strategy where the interpreter can be used for
an arbitrary number of executions for every regex, before tiering-up to the
compiler. The only exception is for functional global replaces, where we
eagerly tier-up to native code right away.
To use the tier-up logic --regexp-tier-up=value needs to be set. It is
currently set to 0 by default.
Change-Id: I770857e5eae710a952fe47661cb42957c53848b4
Bug: v8:9566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789299
Commit-Queue: Ana Pesko <anapesko@google.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63623}
The fuzzer found a crash when we want to execute the {valueOf} function
of an imported value for an i64-global. The problem is that we cannot
execute JavaScript at that moment (I did not check why, I guess we open
some scope at some point). I checked the WebAssembly spec now, and it
defines that only numbers are valid values for imported globals. I
adjust our bigint implementation accordingly with this CL, i.e. that
only bigint values are valid as imported i64-globalsl.
I also created github issues to discuss this problem.
R=jkummerow@chromium.org
Bug: chromium:1001804
Change-Id: I47f0b31fab53163346f341ad290fd3c58e7707bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792167
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63621}
This reverts commit 9da3483136
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
Change-Id: I3cc4bb80081c662b1751234bc16a821c20e744be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792166
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63617}
This is a reland of 8b89a7c32d
Reland after disabling the test getting deadlocked with '--gc_stress' flag.
The CL was reverted because of the 'wasm/grow-shared-memory' test from
the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
the known issue (v8:9221) and the deadlocking test is now disabled (
1c8981e3f4).
Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
>
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
>
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}
Bug: v8:9489,v8:9221
Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#63599}
Disable the 'wasm/grow-shared-memory' test from the mjsunit test suite for
all the 'gc_stress' variants. The test is currently disabled only for
executions with the combination of 'gc_stress' and 'slow_path'.
With the --gc-stress flag enabled, the test time outs as a result of
deadlock or fails with the DCHECK error because of the known issue.
Bug: v8:9221
Change-Id: Ia2cbbb6f1e5678e5583176fcdd557bd8760234e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1789290
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Cr-Commit-Position: refs/heads/master@{#63597}
Expressions in class heritage position do not have access to the
inheriting class's private names, only its lexical bindings. The parser
currently uses the same scope chain for both.
This CL makes scopes in class heritage position skip their outer class
when resolving private names. Whether a scope needs to skip is kept as a
bit on various scope-related data structures.
See implementation doc at
https://docs.google.com/document/d/1d3o_SQqcICxfjLMw53OOaiIQux0ppNHQJnjZHtCQLwA
Bug: v8:9177
Change-Id: I77e491a9d4a261131274f12ddf052af7ac31a921
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769486
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63586}
{JavaScriptFrame::GetParameters} allocates a new {FixedArray}, hence
all object references need to be handified to survive that allocation.
R=mstarzinger@chromium.org
Bug: chromium:1000635
Change-Id: I76df5ac109bdb6999fe897bdafaf2175344ecca4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787429
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63583}
This is a reland of 981aafaf97
It adds double checks to LoadFieldByIndex in the optimizing compiler, which
are likely the source of the crashes.
Original change's description:
> Reland "[ic] In-place Double -> Tagged transitions"
>
> This is a reland of 0736599a69.
> This is a reland of 7e1fbe8f34.
>
> Original change description:
> > [ic] In-place Double -> Tagged transitions
> >
> > With no more MutableHeapNumber, we can make Double -> Tagged transitions
> > in-place, at the cost of an extra map check when accessing double fields
> > to make sure they are still doubles.
> >
> > Bug: v8:9606
> > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63374}
>
> TBR=verwaest@chromium.org, tebbi@chromium.org
>
> Bug: v8:9606
> Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63499}
TBR=verwaest@chromium.org
Bug: v8:9606
Bug: chromium:997989
Change-Id: Iccfff8e5c6306c9ee4f6c62767dce883b1c6f743
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784288
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63582}
Implements match indices for regexp, as specified by
https://github.com/tc39/proposal-regexp-match-indices,
a stage 3 TC39 proposal. This implementation is hidden
behind the '--harmony-regexp-match-indices' flag.
Regexp match indices extends the JSRegExpResult object
with an array of indices of matches, as well as a
dictionary of capture names to match indices.
Bug: v8:9548
Change-Id: Ia9efcee00d997dda6158539b8d0f4c4e5965e5e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771379
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63581}
This is a safe to merge hot-fix to tackle https://crbug.com/983764.
To be reverted after merging to M77.
Bug: chromium:983764
Change-Id: I3cd27481f224b352ef6bcf9dde21a8f77616acff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1786285
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63570}
Async functions were not correctly fixed up for code coverage, which
caused an additional uncovered range to be reported between a return
statement and the closing bracket.
This CL adds code that detects such ranges, and removes them, similarly
to how the ranges are removed for normal functions. The removal process
is different, because the parser rewrites async functions to contain a
try-catch handling promise rejection.
Change-Id: I73b08d64be74d26c32f2f9652d027430d4671251
Bug: chromium:981313, v8:8381
Change-Id: I82a7f0c54d3a48609ef5255a7659d9557e163566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782837
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63561}
This is a reland of ab089c7864, after
making a flaky test more robust.
Original change's description:
> [turbofan] Prepare for moving part of CreateGraph into the background
>
> - Pass Refs, not Handles, to graph builder, and drop bytecode array argument
> (get it from SFI instead).
> - Add some fields to FeedbackVectorRef that are needed to avoid heap access
> in BytecodeGraphBuilderPhase.
> - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more
> than just the feedback slots.
> - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such
> that CreateGraph is last.
>
> Bug: v8:7790
> Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63515}
Bug: v8:7790
Change-Id: Ia6f4c1ebd82dea93c14437514d0e25b730523f75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781694
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63545}
Use the position of commas in async arrow expressions to mark the
initializer position of any parameters that might have been set in the
preceding parameter.
This extends https://chromium-review.googlesource.com/c/v8/v8/+/1710671
to async arrow heads.
Bug: v8:8510, chromium:997320
Change-Id: I98e0ac817c7f53fbf1dced98fb6891a386ee7803
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781057
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63542}
This reverts commit 8b89a7c32d.
Reason for revert: GC Stress tests timing out.
See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272
Original change's description:
> Update GetIterator bytecode to load and call object[Symbol.iterator]
>
> The functionality of the GetIterator bytecode introduced previously is
> now extended from loading the @@iterator property to calling the property
> as well. This change basically absorbs the functionality of additional
> two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
> Importantly, this change handles the cases of eager and lazy deoptimization
> in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
> eager deopt of the CallProperty0 bytecode, using the continuation builtins.
> This mechanism can work as a template for the future bytecode that require
> handling such inter-bytecode deopt scenario. The tests evaluating the eager
> and lazy deopt scenarios are also included.
>
> Bug: v8:9489
> Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63528}
TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9489
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63536}
The functionality of the GetIterator bytecode introduced previously is
now extended from loading the @@iterator property to calling the property
as well. This change basically absorbs the functionality of additional
two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
Importantly, this change handles the cases of eager and lazy deoptimization
in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
eager deopt of the CallProperty0 bytecode, using the continuation builtins.
This mechanism can work as a template for the future bytecode that require
handling such inter-bytecode deopt scenario. The tests evaluating the eager
and lazy deopt scenarios are also included.
Bug: v8:9489
Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63528}
This CL adds initial tests for the tier-up logic.
Change-Id: I6e6ff69604b14387e81b08d178f98d2227b4f496
Bug: v8:9566
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776080
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@{#63503}
This is a reland of 0736599a69.
This is a reland of 7e1fbe8f34.
Original change description:
> [ic] In-place Double -> Tagged transitions
>
> With no more MutableHeapNumber, we can make Double -> Tagged transitions
> in-place, at the cost of an extra map check when accessing double fields
> to make sure they are still doubles.
>
> Bug: v8:9606
> Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63374}
TBR=verwaest@chromium.org, tebbi@chromium.org
Bug: v8:9606
Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63499}
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}
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 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}
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 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}
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}
By marking maps detached from the transition tree as prototypes, we'll
automatically stop tracking transitions from those detached fast maps. That
allows us to quickly check whether a map is detached (or the initial map
anyway); and saves memory. We can use this information to ignore sibling type
feedback when parsing a JSON array with many distinctly shaped json objects.
Bug: chromium:993980
Change-Id: I86d493ac2cabec2c31c6e322ad5c5a7ace059dfc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771778
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63403}
For stores with Double feedback, StoreIC needs to check that the
representation is still Double before doing the store, in case it
accidentally tries to write to an object or worse, mutate a non-mutable
HeapNumber.
Bug: v8:9606
Bug: chromium:997485
Change-Id: I51e0953b40f752648c5e86b8644c23baf636367e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768373
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63402}
This reverts commit 9460101cdb.
Reason for revert: Causes confusion on Blink side, as it introduces
an object with >=2 internal fields that is not a wrapper (see bug).
Bug: chromium:996681
Change-Id: I275b5a064a4ee8c73c05f97be322924a3bc5370e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1769148
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63386}
Even when a field is marked const, we may emit multiple consecutive in-literal stores to that field. That is, in 'JSNativeContextSpecialization::BuildPropertyStore', when the access mode is 'kStoreInLiteral' and we are accessing a const field, we may produce a StoreField node, even though another StoreField (that stores something other than 'Uninitialized') to the same const field dominates it. This appears to be sound, since earlier stores to literals cannot be observed anyways.
Unfortunately this behavior conflicts with the double const store invariant in load elimination: Roughly speaking, we assume that load elimination may never observe two consecutive const stores to the same field on the same object.
The apparent solution would be to treat 'kStoreInLiteral' accesses like regular 'kStore' accesses: For consecutive stores to const properties we don't emit StoreField, but instead emit code that checks whether the value about to be written is equivalent to the previously written one, and otherwise deopt ('DeoptimizeReason::kWrongValue'). Unfortunately this turns out impractical, since for 'kStoreInLiteral' accesses we can't easily decide whether we're dealing with the first such store or one of the consecutive ones. Also see this abandoned CL: https://chromium-review.googlesource.com/c/v8/v8/+/1762020.
This CL instead adds an exception to the invariant in load elimination. We track whether a store arose from a 'kStoreInLiteral' access, and use this information when visiting StoreField nodes in load elimination.
R=neis@chromium.org, tebbi@chromium.org
Bug: chromium:987205
Change-Id: I8829752aa0637e9599677d20aad2d706d40d7fe6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763535
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Schmid <gsps@google.com>
Cr-Commit-Position: refs/heads/master@{#63385}
This reverts commit 5db04cc0dd.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> Revert "[regexp] Only append to JSRegExpResult's initial map if we add descriptor"
>
> This reverts commit dc1cc2232b.
>
> Revert "[regexp] Implement the match indices proposal"
>
> This reverts commit 9460101cdb.
>
> Reason for revert: Causes confusion on Blink side, as it introduces
> an object with >=2 internal fields that is not a wrapper (see bug).
>
> Bug: chromium:996681
> Change-Id: I5c167e9e15bfbec2aa6b843e3063ead5d52fb26c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768897
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63376}
TBR=yangguo@chromium.org,sigurds@chromium.org,joshualitt@chromium.org
Change-Id: Ic58fc3fc83faaf86bd895da29eacb7d51c443beb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:996681
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768584
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63379}
With this Cl, a function that has been marked for deoptimization will
not be reported as optimized. This protects against potential races
where an mjsunit tests assertUnoptimized, and the optimized code for
the function has been marked for deoptimization, but not been disposed
of yet.
The potential for this race has been discovered in the context of bug
v8:9563, but this CL is not a fix for that bug.
Change-Id: I89d8aa85f19033e6b823324b3307b95d61367147
Bug: v8:9563
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763543
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63377}
This reverts commit dc1cc2232b.
Revert "[regexp] Implement the match indices proposal"
This reverts commit 9460101cdb.
Reason for revert: Causes confusion on Blink side, as it introduces
an object with >=2 internal fields that is not a wrapper (see bug).
Bug: chromium:996681
Change-Id: I5c167e9e15bfbec2aa6b843e3063ead5d52fb26c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768897
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63376}
In order to reflect web reality, TC39 has made some slight changes to
name descriptors, see https://github.com/tc39/ecma262/pull/1490 for
details. V8 was mostly already in compliance with these changes, but
ThrowTypeError and anonymous classes needed some slight changes.
Bug: v8:9646
Change-Id: I163238954938f0c005e3adbc61b90498e01436da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1764622
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63373}
While we only need to check stability of the receiver map if its
inference was "unreliable", we must check stability of each prototype's
map unconditionally.
Bug: chromium:997100
Change-Id: I20071ac9eb74c810ad2ab1d78abfb54a1a006c29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768576
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63364}
This preserves the object identity of a {WebAssembly.Function} instance
that is being re-exported by a module. Such functions are considered to
have an internal [[FunctionAddress]] slot and hence require their object
identity to be preserved (similar to {WasmExportedFunction} already).
R=jkummerow@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I88ba75fcd91ce04440008467f3b218a1ac3047db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763545
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63346}
For import wrappers, we add a special "callable" parameter as the last
parameter. This parameter is not set in the TurboFan graph but in the
code generator. Therefore this parameter has to be allocated in a
special register and cannot be lowered generically. With this CL we
detect in the CallDescriptor lowering if the last parameter is this
special "callable" parameter. If so, we preserve it in the lowered
CallDescriptor in the same register.
R=jkummerow@chromium.org
Bug: v8:7741
Change-Id: I884baa41813011c811612ec84f4e3cfe86a0e83a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762014
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63344}
This CL adds a mechanism that prevents the RuntimeProfiler from
triggering optimization of a function after
%PrepareFunctionForOptimization has been called. This is useful to
prevent flakiness in tests, as sometimes a function that already
got deoptimized would receive a new code object from a concurrent
compile that was triggered by a heuristic just in the right moment
for the assertUnoptimized test to fail. For example, the following
was happening:
PrepareFunctionForOptimization
[marking `testAdd` for optimized recompilation, reason: small function]
[concurrently compiling method `testAdd` using TurboFan]
[manually marking `testAdd` for non-concurrent optimization]
[synchonously compiling method `testAdd` using TurboFan]
[synchonously optimizing `testAdd` produced code object 0xAAAA - took 1.638 ms]
Runtime_GetOptimizationStatus OPTIMIZED `testAdd` (code object 0xAAAA)
DeoptimizeFunction `testAdd` with Code Object 0xAAAA
[concurrently optimizing `testAdd` produced code object 0xBBBB - took 3.377 ms]
Runtime_GetOptimizationStatus OPTIMIZED `testAdd` (code object 0xBBBB)
Bug: v8:9563
Change-Id: Ia4c846aba95281589317d43b82383e70fe0a35f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763546
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63343}
This CL was reviewed originally in https://crrev.com/c/1518181.
Bug: v8:7741
Change-Id: Iddb139a24c4b9aee6694e20cb5d04e9f9887160c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752859
Auto-Submit: Sven Sauleau <sven@cloudflare.com>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63321}
This CL implements the nullish operator in bytecode as defined by:
https://github.com/tc39/proposal-nullish-coalescing. It can be
enabled by passing '--harmony-nullish'.
Nullish is similar to logical operators, but instead of truthy/falsey
values, it short circuits when it evaluates a null or undefined value.
Bug: v8:9547
Change-Id: Ia0f55877fc2714482b5547942baef9733537d1b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738568
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63317}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I88a6c7e9236a549808707c72e40a63302b7747a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763527
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63312}
This just adds a test case checking against the current behavior, but
expectations might change once the proposal is clarified. For details
see: https://github.com/WebAssembly/js-types/issues/11R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I2fc502460c0a8094a414d138703b75497b2d1c6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762517
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63311}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Ic51b7b4744f7b3ad056a778aecfc4614ca8d6e75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762019
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63299}
Since the mutability of HeapNumbers is determined by their owning
object's descriptor array, we can remove the MutableHeapNumber type
entirely, at the cost of a few fewer DCHECKs and a couple of TODOs
to use the descriptor array information.
This is a necessary step towards a follow-up which allows in-place
Double -> Tagged transitions
Design doc: https://docs.google.com/document/d/1VeKIskAakxQFnUBNkhBmVswgR7Vk6T1kAyKRLhqerb4/
Bug: v8:9606
Change-Id: I13209f9c86f1f204088f6fd80089e17d956b4a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743972
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63294}
This patch implements the declaration of private accessors.
When iterating over the class properties, we track private
accessors associated with the same name in a ZoneHashMap.
Once we get to all the necessary components for a private name
(we know statically whether we should expect only a setter,
only a getter, or both), we emit a call to a runtime function
`CreatePrivateAccessors` that creates an AccessorPair, and
store the components in it. The AccessorPair is then associated
with the private name variable and stored in the context
for later retrieval when the private accessors are accessed.
Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
Bug: v8:8330
Change-Id: Ie6d3882507d143b1f645d7ae82b21b7358656e89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725670
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63284}
Fixes bytecode mismatch between lazy and non-lazy where "this" was
marked as maybe assigned in constructors that called the super
constructor. Since this will return the hole in cases where it was not
yet initialized by super (and the hole is explicitly handled by
JSContextSpecialization::ReduceJSLoadContext), it's safe to treat it as
a constant in all cases. In the case of lazy compilation case, "this"
is never added to the ScopeInfo so is never seen as mutable.
Bug: chromium:994719
Change-Id: I43478fbc626b19eb1533aa9dec61b7f276ae140b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762025
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63283}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I168741d382373ec47ebe0517ce7803732cbb3b24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762011
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63276}
This adds type reflection support to the {WebAssembly.Module.exports} as
well as {WebAssembly.Module.imports} method. It also refactors existing
reflective code to use the internal instead of the public embedder API,
which is slightly more efficient anyways.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I5f20ea57261f6433b8d86f55054216bf96b41382
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760826
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63273}
Implements match indices for regexp, as specified by
https://github.com/tc39/proposal-regexp-match-indices,
a stage 3 TC39 proposal. This implementation is hidden
behind the '--harmony-regexp-match-indices' flag.
Regexp match indices extends the JSRegExpResult object
with an array of indices of matches, as well as a
dictionary of capture names to match indices.
Bug: v8:9548
Change-Id: I9866a2d1f5af6a507de710357cb5e74c694e7558
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1734937
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63272}
This brings the graph builder in sync with the serializer (and
exponentiation in sync with the other binary operators).
Bug: chromium:995430, v8:7790
Change-Id: I809b6f3756f75392cdc6747f8bcee8cdf0ee0f74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762013
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63269}
... by making the operator have a control output, since we could deopt
after my last change.
Bug: chromium:995562, v8:7790
Change-Id: Ibc8c44708b4d43c4b2c3dfab2fd8fdf79c7ea671
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762010
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63268}
The optional chaining bytecode in delete expressions was
unconditionally jumping if the receiver was nullish, instead
of just when the property was an actual optional chain link.
This change adds the missing check around the jump.
Change-Id: Ic7bed58be4ae62d157e63e4f77666b1abd1f802d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1755264
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63251}
Test mjsunit/regress/regress-992389 explicitly sets the jitless flag
when run.
Skip this test when run on builds without embedded-builtins.
Bug: v8:9632, chromium:992389
Change-Id: Ieb52a33006b1104080d8f5adb8c4f2c36e4413af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758317
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63240}
This CL adds additional information in PropertyAccessInfos and FieldAccesses about the map that introduced the accessed field. We use this information to prevent load elimination from incorrectly optimizing certain accesses marked const.
Prior to this CL, load elimination simply stored information about eliminatable field accesses based on objects (identified by nodes in the graph) and offsets (i.e., statically known ones). In the presence of const stores and loads this is insufficient, since a single object (in the above sense) may contain distinct *const* properties at the same offset throughout its lifetime. As an example, consider the following piece of code:
let obj = {};
obj.a = 0;
obj[1024] = 1; // An offset of >=1024 forces an elements-kind transition
delete obj.a;
obj.b = 2;
assertEquals(obj.b, 2);
In this scenario, *both* the first ('obj.a = 0') and the second ('obj.b = 2') store to a field will be marked const by the runtime. The reason that storing to 'a' above ends up being marked const, is that 'a' before and after the elements-kind transition is encoded in separate transition trees. Removing 'a' ('delete obj.a') only invalidates const-ness in the dictionary-elements transition tree; not the holey-elements one used at the time of 'obj.a = 0'.
The above situation on its own violates an invariant in load elimination. Namely, we assume that for the same object and offset, we will never encounter two const stores. One can extend the above snippet to coax load-elimination into producing incorrect results. For instance, by "hiding" 'obj.b = 2' in an unoptimized function call, the consecutive load from 'b' will incorrectly produce 0, violating the assert.
R=neis@chromium.org, tebbi@chromium.org
Bug: chromium:980183, chromium:983764
Change-Id: I576a9c7efd416fa9db6daff1f42d483e4bd369b4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751346
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63226}
Fixes DCHECK failure in DropStackFrameCacheCommon by returning early if
the source_position_table is Exception.
Bug: chromium:990582, v8:8510
Change-Id: I671f3e0cdc9f880dedf8ecd2fffb1083229dc6dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752856
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63209}
Otherwise there is a mismatch between eager parsing (where the reciever
is marked as MaybeAssigned) and lazy parsing (where the receiver is
deserialized and not marked MaybeAssigned) for arrow functions that
have an inner scope that calls eval.
BUG=chromium:989914
Change-Id: I8b8b78140858985a75a971b0e0a95bd61463457b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1752851
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63206}
When GC triggered while an exception is pending, a read to
memory that was no longer valid could happen while backtracking in the
regexp interpreter (introduced with commit fb0df2c).
This CL prevents this dirty read, that could have been a security issue.
Bug: chromium:992389, v8:9575
Change-Id: Ie1acd6faa16665e211666c6a8dcf2a9d74e0c886
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751342
Commit-Queue: Patrick Thier <pthier@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63195}
When a RelocatingCharacterStream is Seeked, it's buffer_pos_ could be set a non-zero value.
However, UpdateBufferPointers was assuming the position was zero to relocate the buffer_start_
and buffer_end_, which would lead to the stream becoming misaligned. Fix this and add a
unittest and the clusterfuzz script which highlighted the issue.
BUG=chromium:991133
Change-Id: I20dd510b3dcc5df6df058b7e06d2c8a838aef855
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751782
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63190}
This reverts commit d1a4706af9.
Reason for revert: Experiment over.
Original change's description:
> Reland "[ptr-compr][arm64] Temporarily enable pointer compression on arm64"
>
> This is a reland of f5611402f7
>
> Original change's description:
> > [ptr-compr][arm64] Temporarily enable pointer compression on arm64
> >
> > ... and make sure that the arm64 ptr-compr bots proceed testing V8 without
> > pointer compression in order to keep testing the other config.
> >
> > Commented out the 'extra' variant since it was crashing. Opened a bug
> > regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568
> >
> > Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654
> >
> > Bug: v8:7703
> > Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216
> > Reviewed-by: Tamer Tas <tmrts@chromium.org>
> > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63019}
>
> Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng
> Bug: v8:7703
> Change-Id: I1a82b87bf6db4e6d100aeffc29dae60ba73d8119
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730998
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63043}
TBR=machenbach@chromium.org,tmrts@chromium.org,solanes@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7703
Change-Id: I86a801d44ad4ea14b1388ad8ca6109cc8a57a7d7
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1746470
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63148}
The spec says we have to insert some wrapper code with extra line breaks
in it, but this confuses users when they see stack traces as the line
numbers come from the code with the wrapper, instead of the original.
This CL sets line_offset on the script to indicate that line numbers
should be offset by the 2 extra line breaks when reading them out e.g.
for the purpose of stack traces.
Bug: chromium:109362
Change-Id: Ib608e1043c38b595b1466766f7592e993ee3b996
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741660
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63127}
With lazy feedback allocation, we don't have feedback vectors when function
starts executing. If we mark the function on the first execution we would
be missing feedback for the initial part of the function and hence the
optimized code will not be useful.
This cl resets the optimization markers on OSR if the invocation count of
the function is less than 1. We may still do wasted optimizations if the
function is hot enough for optimizing but not for OSRing. In the long term
we may want to fix it differently. This fix covers the most common cases
in benchmarks.
Bug: chromium:987523
Change-Id: I1cfe82e6b9f95278b77c99b77d4b981828b5c0ab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1739373
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63124}
Each LHS expression that contains an optional chain of some form is
wrapped in an OptionalChain node. This root node allows us to use a
single jump location for every individual item in the chain,
improving the performance and simplifying the implementation.
Bug: v8:9553
Change-Id: I678563928b2dbfd6200bff55801919d4fd816962
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1723359
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63120}
This patch stores the home objects in private methods that
access super properties.
Bug: v8:8330
Change-Id: I2507fda0bd70183f02d162ec50a5be76c248f0ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724900
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#63113}
Ongoing cleanup to use the same term everywhere.
Bug: chromium:913887
Change-Id: Ifc4d4de0c2dfd9f1150e61d64cf7f91cf923aa24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738865
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63101}
This cl makes IsLockFree return true for 8 bytes on x64 platforms.
The standard is unfortunately a bit vague on what exactly 'lock free' means.
As a result, we err on the side of caution. We can revisit this, but first
we need the specification to nail down exactly what 'lock free' in this
context.
Bug: v8:8100
Change-Id: I0a6099c6cb95a5581f3e71d0267857b88b4a2f0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735592
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63099}
This is a reland of 159df2488c
Original change's description:
> [ic] Don't transition to premonomorphic state
>
> We used to use premonomorphic state to delay initializing the ICs.
> This optimization was to avoid the cost of setting up handlers if the
> code executed only once. With lazy feedback allocation we no longer
> need this.
>
> This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
> StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
> runtime in the uninitialized state and use the builtin when there
> is no feedback.
>
>
> Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63020}
Change-Id: Ica7eb65649615c2f8410d5b815a98b55cb1cfc4d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731000
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63082}
This reverts commit 5611f70b3d.
Reason for revert: flaky tests: v8:9588, v8:9587
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=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9380, v8:9221, chromium:986318
Change-Id: Ic7381239f4e90d0c437b7e47a5ac6e8bce60f882
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1736747
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63081}
When a fast path was added for Math.hypot, the algorithm was also
simplified. This simplification turns out to be incorrect in some rare
edge cases. This cl reverts back to the original algorithm and converts it to torque.
Original cl: https://chromium-review.googlesource.com/c/v8/v8/+/1684178
Bug: v8:9546
Change-Id: If4e21504732f46081a8de823f50f499917f1a20c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725200
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63070}
For variable proxies in a function inside an eval scope that point to
a dynamic variable in the eval scope, the current scope resolution will
find this variable only when the function is eagerly compiled, as the
eval scope only exists during top-level eval compilation. This causes
a mismatch between lazy- and eager- compiled functions.
With this patch, we skip these dynamic variables during lookup, so that
the lookup for the variable proxy always finds a kDynamicLocal or
kDynamicGlobal, both when compiled lazily and eagerly. This is a minor
pessimisation of performance (as we know that the lookup has to be
dynamic), but unblocks other improvements which require idempotent
bytecode generation (such as lazy source positions).
Note that the alternative, of simply not tracking dynamic variables on
the eval scope at all, is not viable due to needing this information
during conflict detection.
Bug: v8:8510
Bug: v8:9511
Change-Id: Ifa72ec05e9a97b7be418912340081b9656765fd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733077
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63051}
This makes sure the "parameters" and "results" properties of the passed
FunctionType object can be arbitrary iterable objects, not just plain
JavaScript arrays.
R=clemensh@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Icba18c418e549deba9fff1855be4956813b1a953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733071
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63049}
It's too slow and flakes on "V8 Linux - full debug"
Change-Id: I2a83a7a2de6a3865d230edb847a658b1b8b23bec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733076
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63047}
This is a reland of f5611402f7
Original change's description:
> [ptr-compr][arm64] Temporarily enable pointer compression on arm64
>
> ... and make sure that the arm64 ptr-compr bots proceed testing V8 without
> pointer compression in order to keep testing the other config.
>
> Commented out the 'extra' variant since it was crashing. Opened a bug
> regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568
>
> Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654
>
> Bug: v8:7703
> Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63019}
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng
Bug: v8:7703
Change-Id: I1a82b87bf6db4e6d100aeffc29dae60ba73d8119
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730998
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63043}
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}
When the flag is on and some of the functions don't have bytecode,
we should gracefully print "no bytecode" instead of crashing.
Bug: chromium:983267
Change-Id: Id4e3385cd871a2dd5bead38c29a41b38319cc8d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731003
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63031}
now that we are shipping this by default, we can remove the flag.
Change-Id: I298691df3eec934a5add1aa2a2748a0f3a884ab6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726452
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63026}
This reverts commit 159df2488c.
Reason for revert: Breaks large-classes-properties test (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906338563361079200/+/steps/Bisect_159df248/0/steps/Retry_-_isolates/0/logs/large-classes-properties/0)
Original change's description:
> [ic] Don't transition to premonomorphic state
>
> We used to use premonomorphic state to delay initializing the ICs.
> This optimization was to avoid the cost of setting up handlers if the
> code executed only once. With lazy feedback allocation we no longer
> need this.
>
> This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
> StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
> runtime in the uninitialized state and use the builtin when there
> is no feedback.
>
>
> Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63020}
TBR=mythria@chromium.org,verwaest@chromium.org
Change-Id: I4fad4e8b881d4a3f8d12149e1797b217a317eaee
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730995
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63023}
We used to use premonomorphic state to delay initializing the ICs.
This optimization was to avoid the cost of setting up handlers if the
code executed only once. With lazy feedback allocation we no longer
need this.
This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
runtime in the uninitialized state and use the builtin when there
is no feedback.
Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63020}
... and make sure that the arm64 ptr-compr bots proceed testing V8 without
pointer compression in order to keep testing the other config.
Commented out the 'extra' variant since it was crashing. Opened a bug
regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568
Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654
Bug: v8:7703
Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63019}
This reverts commit df8e617772.
Reason for revert: Multiple flakes in apparently related areas:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906409837768155568/+/steps/Check__flakes_/0/logs/BackingStoreTest.RacyGrowWasmMem.../0
Original change's description:
> "Reland x3 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5aeba
>
> 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.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221,chromium:986318
> TBR=ulan@chromium.org
>
> Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63007}
TBR=mstarzinger@chromium.org,titzer@chromium.org,mlippautz@chromium.org
Change-Id: If0266e5893b1325a332d5986337fa7ece2cb6943
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221, chromium:986318
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1729549
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63011}
This is a reland of 4b15b984ad
Updates since original: fix an arithmetic overflow bug, remove an invalid
DCHECK, add a unit test that would trigger that DCHECK.
Original change's description:
> [regexp] Better quick checks on loop entry nodes
>
> Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
> change is inspired by attempting to exit earlier from generated RegExp
> code, when no further matches are possible because any match would be
> too long. The motivating example this time is the following expression,
> which tests whether a string of Unicode playing cards has five of the
> same suit in a row:
>
> /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
>
> A human reading this expression can readily see that any match requires
> at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
> each repeated option reports its minimum distance to the end of a match
> as zero. This is correct, because the LoopChoiceNode's behavior depends
> on additional state (the loop counter). However, the preceding node, a
> SET_REGISTER action that initializes the loop counter, could confidently
> state that it consumes at least 10 characters. Furthermore, when we try
> to emit a quick check for that action, we could follow only paths from
> the LoopChoiceNode that are possible based on the minimum iteration
> count. This change implements both of those "could"s.
>
> I expect this improvement to apply pretty broadly to expressions that
> use minimum repetition counts and that don't meet the criteria for
> unrolling. In this particular case, I get about 12% improvement on the
> overall UniPoker test, due to reducing the execution time of this
> expression by 85% and the execution time of another similar expression
> that checks for n-of-a-kind by 20%.
>
> Bug: v8:9305
>
> Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62963}
Bug: v8:9305
Change-Id: I992070d383009013881bf778242254c27134b650
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726674
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#63009}
This is a reland of bc33f5aeba
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.
R=mlippautz@chromium.org
BUG=v8:9380,v8:9221,chromium:986318
TBR=ulan@chromium.org
Change-Id: I6c49e2425029b5664ef1c68dab8b5146f4ed0ff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719191
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63007}
The DCHECK related to a time when dictionary mode prototypes were the payload
of complex data driven handlers. Now the additional data is used to hold
entirely different kinds of objects. The DCHECK made no sense anymore. Cleaning
up the names makes this clearer.
Bug: chromium:986187
Change-Id: I7173d7d2824396c04c01acb4ceb74693ee9ce6b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724215
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62993}
This method will be used for a test with multiple code spaces, to
encode large function indexes. The current implementation in
{wasmI32Const} just always uses 5 bytes for encoding the LEB value.
This CL adds a {wasmSignedLeb} function which properly encodes the
value, and adds tests for that.
Drive-by: Clean up the rest of {test-wasm-module-builder.js}.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ide2d90eed9d40aa28df680fbb413275346d9c0b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725623
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62990}
This patch adds:
- VariableMode::kPrivateMethod
- VariableMode::kPrivateSetterOnly
- VariableMode::kPrivateGetterOnly
- VariableMode::kPrivateGetterAndSetter
And replace the previous RequiresBrandCheckFlag by inferring
whether the brand check is required from these VariableModes.
It is then possible to check duplicate non-complementary
accessors in the parsers and throw early errors, and allow
complementary accessors to be associated with the same
private name variable.
This patch also adds the following AssignType:
- PRIVATE_METHOD
- PRIVATE_GETTER_ONLY
- PRIVATE_SETTER_ONLY
- PRIVATE_GETTER_AND_SETTER
corresponding to the new VariableModes so that it's possible
to generate specialized code for different type of
private accessor declarations.
Design doc: https://docs.google.com/document/d/10W4begYfs7lmldSqBoQBBt_BKamgT8igqxF9u50RGrI/edit
Bug: v8:8330
Change-Id: I0fb61b1be248630d1eadd74fb16d7d64a421f4c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695204
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62988}
The tests rely too much on OS state (thread allocation) to be
predictable.
Change-Id: I9a562369a3c72522630a23ee47e3e819b9411c65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725626
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62987}
Previously, this was run as a microtask and this CL changes it to run
as a separate task as mandated by the current WeakRef spec.
This CL also introduces a FinalizationGroup type to the V8 API
representing the JSFinalizationGroup. This has a `Cleanup`
function that runs the cleanup callback associated with it.
SetHostCleanupFinalizationGroupCallback is added to set
the embedder defined HostCleanupFinalizationGroupCallback.
ClearKeptObject is exposed on the v8::Isolate to reset the strongly
held set of objects.
The general workflow is the following:
(a) When the GC notices that a given finalization group has dirty
cells, it calls HostCleanupFinalizationGroupCallback with the given
finalization group.
(b) As part of HostCleanupFinalizationGroupCallback, the embedder
enqueues a task that at some point later calls
FinalizationGroup::Cleanup.
(c) At some point in the future, FinalizationGroup::Cleanup is called,
which runs the cleanup callback of the finalization group.
This patch also includes d8 changes to use these new APIs. Currently,
d8 cycles through the enqueued finalization groups after a synchronous
turn (and it's microtask checkpoint) and runs the cleanup callbacks.
Change-Id: I06eb4da2c103b2792a9c62bc4b98fd4e5c4892fc
Bug: v8:8179
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655655
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62984}
This drops possible remaining pattern errors from the access target. This is
necessary since sub patterns with default values (assignment expression) aren't
otherwise identifiable as being property accesses.
Bug: v8:9560
Change-Id: Ie6781c0d161e00790268f7d9db81377d045f93b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725624
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62982}
This reverts commit 4b15b984ad.
Reason for revert: UBSan failure (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906578530303352544/+/steps/Check/0/logs/regress-126412/0).
Original change's description:
> [regexp] Better quick checks on loop entry nodes
>
> Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
> change is inspired by attempting to exit earlier from generated RegExp
> code, when no further matches are possible because any match would be
> too long. The motivating example this time is the following expression,
> which tests whether a string of Unicode playing cards has five of the
> same suit in a row:
>
> /([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
>
> A human reading this expression can readily see that any match requires
> at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
> each repeated option reports its minimum distance to the end of a match
> as zero. This is correct, because the LoopChoiceNode's behavior depends
> on additional state (the loop counter). However, the preceding node, a
> SET_REGISTER action that initializes the loop counter, could confidently
> state that it consumes at least 10 characters. Furthermore, when we try
> to emit a quick check for that action, we could follow only paths from
> the LoopChoiceNode that are possible based on the minimum iteration
> count. This change implements both of those "could"s.
>
> I expect this improvement to apply pretty broadly to expressions that
> use minimum repetition counts and that don't meet the criteria for
> unrolling. In this particular case, I get about 12% improvement on the
> overall UniPoker test, due to reducing the execution time of this
> expression by 85% and the execution time of another similar expression
> that checks for n-of-a-kind by 20%.
>
> Bug: v8:9305
>
> Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62963}
TBR=jgruber@chromium.org,seth.brenith@microsoft.com
Change-Id: Iac085b75e054fdf0d218987cfe449be1f1630545
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9305
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725621
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62977}
This is a reland of a0728e869b
Original change's description:
> [d8] Remove maximum workers limitation
>
> This CL refactors the lifetime management of the v8::Worker C++ object
> and in the process lifts the 100 maximum worker limitation. To do this,
> it uses a Managed<v8::Worker> heap object and attaches the managed to
> the API worker object.
>
> R=mstarzinger@chromium.org
> BUG=v8:9524
>
> Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62932}
Bug: v8:9524
Change-Id: I7d903fb12ddb00909a9429455f46c55db2fd02de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722562
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62974}
Serialize for all cases of JSNativeContextSpecialization::ReduceJSInstanceOf.
Bug: v8:7790
Change-Id: I147991353b86619808257a92961b7051105511f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722558
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62965}
Like the predecessor change https://crrev.com/c/v8/v8/+/1702125 , this
change is inspired by attempting to exit earlier from generated RegExp
code, when no further matches are possible because any match would be
too long. The motivating example this time is the following expression,
which tests whether a string of Unicode playing cards has five of the
same suit in a row:
/([🂡-🂮]{5})|([🂱-🂾]{5})|([🃁-🃎]{5})|([🃑-🃞]{5})/u
A human reading this expression can readily see that any match requires
at least 10 characters (5 surrogate pairs), but the LoopChoiceNode for
each repeated option reports its minimum distance to the end of a match
as zero. This is correct, because the LoopChoiceNode's behavior depends
on additional state (the loop counter). However, the preceding node, a
SET_REGISTER action that initializes the loop counter, could confidently
state that it consumes at least 10 characters. Furthermore, when we try
to emit a quick check for that action, we could follow only paths from
the LoopChoiceNode that are possible based on the minimum iteration
count. This change implements both of those "could"s.
I expect this improvement to apply pretty broadly to expressions that
use minimum repetition counts and that don't meet the criteria for
unrolling. In this particular case, I get about 12% improvement on the
overall UniPoker test, due to reducing the execution time of this
expression by 85% and the execution time of another similar expression
that checks for n-of-a-kind by 20%.
Bug: v8:9305
Change-Id: I319e381743967bdf83324be75bae943fbb5dd496
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704941
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62963}
Fixes a bytecode mismatch for arrow functions with default arguments
between eager and lazy compilation. In the former case, parameters with
default values are marked as assigned even if the value never changes
within the function because the parser does not know it's an
arrow-function at the point it sees the assignment.
So this changes ArrowHeadParsingScope::ValidateAndCreateScope to clear
the is_assigned flag on its parameter VariableProxies before it binds
them.
Bug: chromium:988304, v8:8510
Change-Id: I68bf205c73471386181e5fdcec6c8c3b2e527c8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724384
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62962}
This makes function objects constructed via the {WebAssembly.Function}
constructor callable directly from JavaScript (not just from within
WebAssembly modules). Semantics are as if the function performed the
transition JS-to-Wasm and then Wasm-to-JS in sequence.
R=clemensh@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Ic7dcf36ccfda1b473f2541e49419f4d2ee38bc2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720809
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62953}
This reverts commit a0728e869b.
Reason for revert: Times out on Windows & debug builds - https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20nosnap%20-%20shared/34484
Original change's description:
> [d8] Remove maximum workers limitation
>
> This CL refactors the lifetime management of the v8::Worker C++ object
> and in the process lifts the 100 maximum worker limitation. To do this,
> it uses a Managed<v8::Worker> heap object and attaches the managed to
> the API worker object.
>
> R=mstarzinger@chromium.org
> BUG=v8:9524
>
> Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62932}
TBR=mstarzinger@chromium.org,titzer@chromium.org,clemensh@chromium.org
Change-Id: I3a27937cba13b5413390f49268a107c184515153
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720590
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62937}
Use the position of commas in arrow expressions to mark the initializer
position of any parameters that might have been set in the preceding
parameter.
To enable this, this makes variable_list_ in ExpressionParsingScope a
ScopedList<pair<VariableProxy*, int>> and changes ScopedList::at to
return references so its elements can be modified in place.
This fixes a source of bytecode mismatches when collecting source
positions lazily and is a second attempt at fixing this after
https://chromium-review.googlesource.com/c/v8/v8/+/1683267 introduced
problems due to destructuring.
Bug: chromium:980422, chromium:981701, v8:8510
Change-Id: I948f89f34fb75d7463a13183e363f7f96ad09d13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710671
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62936}
This is short-term fix for flaky failures on GC fuzzer. The closures
g1 and g2 have the same SFI and pending optimzed table treats them as
a single entry. This cl, adds %PrepareFunctionForOptimize after one of
them is optimized.
Bug: v8:9556
Change-Id: I1fd72da1baa5de2f7650e080f9b6d04b69dd6a16
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719188
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62934}
This CL refactors the lifetime management of the v8::Worker C++ object
and in the process lifts the 100 maximum worker limitation. To do this,
it uses a Managed<v8::Worker> heap object and attaches the managed to
the API worker object.
R=mstarzinger@chromium.org
BUG=v8:9524
Change-Id: I279b7aeb6645a87f9108ee6f572105739721cef4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1715453
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62932}
- Move SerializePrototype out of DependOnStablePrototypes into
ComputePropertyAccessInfo.
- Brokerize JSNativeContextSpecialization::InferHasInPrototypeChain.
- Brokerize JSNativeContextSpecialization::ReduceJSOrdinaryHasInstance
(modulo the call to ReduceJSInstanceOf).
- Brokerize JSNativeContextSpecialization::ReduceJSHasInPrototypeChain.
- Serialize for JSCallReducer::ReduceObjectPrototypeIsPrototypeOf.
- Serialize for JSNativeContextSpecialization::ReduceJSInstanceOf. This
is still incomplete.
Bug: v8:7790
Change-Id: Ic56eab5ddd8d725a13d2980e5b55db53ae82e822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709408
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62920}
Preparing the value for storing into a typed array is user visible
operation in some cases (for ex: calling ToNumber). To avoid doing this
conversion twice pass the converted to the runtime when bailing out
from the handlers.
Bug: chromium:981236
Change-Id: I3de23d317d22cd6c201fe8a4db30014f4cf76251
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692932
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62879}
This reverts commit 26dad80ff5.
Reason for revert: Breaks d8, see https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/22272
Original change's description:
> [d8] Cleanup message queues
>
> Simplifies some of the logic of message queues in d8 and makes sure
> to delete any in-flight messages upon worker termination. Drive-by
> cleanups of some other small d8 vestiges.
>
> R=clemensh@chromium.org
> BUG=v8:9524
>
> Change-Id: I587c0cb3eeed88107e7dba552389057f07c15c43
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710673
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62873}
TBR=titzer@chromium.org,clemensh@chromium.org
Change-Id: Ibc15d9fb76698a2bad51e3842392634fb2f0246b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9524
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714877
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62875}
Simplifies some of the logic of message queues in d8 and makes sure
to delete any in-flight messages upon worker termination. Drive-by
cleanups of some other small d8 vestiges.
R=clemensh@chromium.org
BUG=v8:9524
Change-Id: I587c0cb3eeed88107e7dba552389057f07c15c43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710673
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62873}
This reverts commit 306cf40344.
Reason for revert: performance regressions / too near branch point
TBR=mslekova@chromium.org
BUG=v8:9380
Change-Id: If77630b73eafbf1190c823199fe2a34361da303f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714867
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62867}
A benign datarace can occur between the array buffer tracker and
using an arraybuffer as an asm.js memory. The former reads the
{is_shared} bit, which should never change, and the latter writes
the {is_asmjs_memory} bit, but no other bits. Since these bits are
packed into a single word, TSAN reports a race.
R=ulan@chromium.org
BUG=v8:9531
Change-Id: Icceff211368e13794b6678b5fd7748fb5b3235bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714647
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62866}
Reland after splitting large classes further.
es6/classes.js is large and causes timeouts and OOM on some of the
configurations.
Bug: v8:9246
Change-Id: I51952447eb6a6b46d78410d5d3798292f5a8d87d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706061
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62864}
Previously, if the new length was less than the current length, we ignored
the "configurable" value and set the length as requested. We already threw
if the new length was greater than or equal to the current length.
New behavior matches the spec and other implementations.
Bug: v8:9460
Change-Id: Idb92fd121bdaa707f6abd2d2082628bbf3541b83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709336
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62855}
This is a reland of bc33f5aeba
Original change's description:
> Reland "[arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of 31cd5d83d3
>
> 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.
> >
> > R=mlippautz@chromium.org
> > BUG=v8:9380,v8:9221
> >
> > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> > Commit-Queue: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62572}
>
> Bug: v8:9380, v8:9221
> Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62809}
Bug: v8:9380, v8:9221
Change-Id: I9a2525753ae2424108d074fa81df5f25d945c824
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709409
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62847}
This is a reland of e55e0aa5bd
Original change's description:
> [runtime] Fix protector invalidation
>
> Protectors trigger when special properties are modified or masked. Previously
> we would check whether the property stored on the holder would invalidate the
> protector. Stores to to the receiver rather than the holder, however, so this
> CL changes holder for receiver, and adds additional checks that were missing.
>
> Bug: v8:9466
> Change-Id: I81bc3d73f91381da0d254e9eb79365ae2d25d998
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708468
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62805}
Tbr: leszeks@chromium.org
Bug: v8:9466
Change-Id: I693c73577ca9a35a271f509770cc1c87e5cc4b73
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1709420
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62829}
This makes sure the language mode of the module is correctly propagated
through the WebAssembly module, so that exported functions are allocated
with the correct language mode. It extends the existing {ModuleOrigin}
enum to consist of three values now.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regress-985154
BUG=chromium:985154
Change-Id: Id7b566738b1e710cc5001b894022bcd0f2c01bc3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708484
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62826}
This reverts commit bc33f5aeba.
Reason for revert: Still failing (OOM on win32): https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/22210
Original change's description:
> Reland "[arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of 31cd5d83d3
>
> 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.
> >
> > R=mlippautz@chromium.org
> > BUG=v8:9380,v8:9221
> >
> > Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> > Commit-Queue: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Ben Titzer <titzer@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Yang Guo <yangguo@chromium.org>
> > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#62572}
>
> Bug: v8:9380, v8:9221
> Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62809}
TBR=ulan@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,titzer@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org
Change-Id: Iea755df9aaa1e95d284135bd0a6681b1340b6832
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9380, v8:9221
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708487
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62811}
This is a reland of 31cd5d83d3
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.
>
> R=mlippautz@chromium.org
> BUG=v8:9380,v8:9221
>
> Change-Id: I48fae5ac85dcf6172a83f252439e77e7c1a16ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1584323
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62572}
Bug: v8:9380, v8:9221
Change-Id: If3f72967a8ebeb067c0edcfc16ed631e36829dbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1691906
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62809}
This reverts commit e55e0aa5bd.
Reason for revert: speculative revert for tsan breakage
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8907588363297935904/+/steps/Check__flakes_/0/logs/regress-437713/0
Original change's description:
> [runtime] Fix protector invalidation
>
> Protectors trigger when special properties are modified or masked. Previously
> we would check whether the property stored on the holder would invalidate the
> protector. Stores to to the receiver rather than the holder, however, so this
> CL changes holder for receiver, and adds additional checks that were missing.
>
> Bug: v8:9466
> Change-Id: I81bc3d73f91381da0d254e9eb79365ae2d25d998
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708468
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62805}
TBR=leszeks@chromium.org,verwaest@chromium.org
Change-Id: Id8fc36525b7c5631589a67073ad1fd5815ea2775
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9466
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708482
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62807}
Protectors trigger when special properties are modified or masked. Previously
we would check whether the property stored on the holder would invalidate the
protector. Stores to to the receiver rather than the holder, however, so this
CL changes holder for receiver, and adds additional checks that were missing.
Bug: v8:9466
Change-Id: I81bc3d73f91381da0d254e9eb79365ae2d25d998
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708468
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62805}
This test fails in --stress-opt mode because backing stores of
memories/arraybuffers that are postMessage()'d leak in d8. In normal
mode, only ~16 memories are allocated, which is not enough to OOM,
but in stress mode, it can be 5x that number. Should be fixed
by upcoming ownership changes.
BUG=v8:9380
R=clemensh@chromium.org
Change-Id: Iecec07d15339cf43b23f128f13d570dfe3b32130
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708475
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62802}
If we flush the bytecode from a SFI we might recompile a JSFunction while the function
still has its old feedback vector. This should usually be fine since the new and old
feedback vectors have the same layout, however some bugs in the parser mean that it's
possible for eagerly and lazily compiled eval functions to have different bytecode and
so potentially different feedback vector layouts.
For now reset the feedback vector if it doesn't have the same size when we compile the
JSFunction, and recreate a new one of the correct layout. This will be replaced with a
CHECK once the parser bugs are fixed.
BUG=chromium:984344,v8:9511
Change-Id: Ib8976f2541516f7a07e4d4ab7dc3c750dfe9b5d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708474
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62800}
With recent spec changes, table.copy of length 0 does not trap anymore,
and we copy backwards whenever src < dst.
R=binji@chromium.org
Change-Id: I48e2b65083565631abc41bf4fdf4971f80fdf440
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706471
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62797}
Adding two small builtins pushed this test over the OOM threshold,
so we disable it for now.
Bug: v8:9488
Change-Id: I6c0696c260cd8ef9e6ee59caec4848aab439fdf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706049
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62783}
If multiple isolates are involved, we can run OOM when creating many
wasm memories, because we only trigger GC in one isolate at a time.
TBR=titzer@chromium.org
No-Try: true
Change-Id: I037b5a13c670c5da2abe54b5045df94637c94f72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706484
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62782}
By having the proposal tests now as part of the wasm-spec-tests, we do
not need them here anymore.
R=clemensh@chromium.orgCC=binji@chromium.org
Change-Id: I2530a4d2e2e8caa6fe8ef4d7e7b8b6da550a5134
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1706475
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62778}
This CL adds more stress-tests for both shared array buffers and
WebAssembly memories. Because of an existing memory leak that will
be fixed in upcoming CLs, some new tests are disabled.
R=mstarzinger@chromium.org
BUG=v8:9380
Change-Id: I2662e3d0a764a032a0c267b2d99e3ccd1a4951d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697252
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62770}
es6/classes.js is large and causes timeouts and OOM on some of the
configurations.
Bug: v8:9246
Change-Id: Iaabfc39dd8f9554e16f67d66ce64acd3dd56b9ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1704103
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62758}
Add CPU trace mark extension for adding a magic instruction like 'cpuid'
to the code stream when perform trace collection.
This feature can be enabled by --expose-cputracemark-as=THE_NAME_YOU_SPECIFIED option.
Change-Id: I33e94793cddf4956dbb3ddddf2f599420aa4a945
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1699749
Commit-Queue: Tianyou Li <tianyou.li@intel.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62749}
RepresentationChanger::GetTaggedPointerRepresentation did not handle
kCompressed cases correctly for BigInts. This led to a crash of BigInt
benchmarks in js-perf-test.
Bug: v8:9407
Change-Id: Id1d60a81afc528c8d4180bd5de9d237f2f0abd0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701848
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62718}
The bytecode graph builder may insert additional jumps for the
SwitchOnGeneratorState bytecode and for loop headers. This plays into
what the graph builder considers dead/alive. We want the serializer to
process all the bytecodes that the graph builder will process, so the
serializer needs to do something similar.
Bug: v8:7790
Change-Id: I1f1d51f4a8951149e365b3c998cef7f613bb4953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1647694
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62712}
When passing promises from other contexts to an `await`, the
--harmony-await-optimization doesn't kick in, and as such the
promise will be wrapped in a "native promise" (from this context).
That means the promises aren't chained immediately, but delayed
via a PromiseResolveThenableJob, which chains these promises on
the next turn of this contexts' microtask queue.
If there's anything happening on the macro task queue in between
this and the point when an exception is raised, the chaining will
have happened and we actually find our way back via the promise
chains. And this CL adds support for exactly that case. For other
cases, it's currently impossible to reconstruct the async stack
unfortunately, but we hope that this will help with the major
use cases, where the developer awaits on I/O.
Bug: v8:7522, v8:8673, v8:9487
Ref: nodejs/node#28680
Change-Id: Icc06c7df12644c2d8d43b6c7580ee06bb8f1024a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701847
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62709}
This test no longer fails with concurrent inlining.
(Concurrent inlining is actually disabled in 'future' at the moment
but will be turned on again soon.)
Bug: v8:9094
Change-Id: I4d3f8021a7accff8cd670f3fef95a7995f1a9ba7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700076
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62702}
Previously, we didn't have access checks for the megamorphic case cause
we'd never get to this IC state for a receiver that doesn't hold the
right private field. But now with lazy feedback allocation we share
the megamorphic case code paths for the uninitialized loads as well,
which exposes our bug.
Bug: chromium:982702
Change-Id: I419406bcfc52575260a85d05520c1662735e15f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697256
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62668}
This change implements lowering of speculative BigInt addition as well as
BigInt heap constants to corresponding int64 versions, if they are used in
a context where the result is truncated to the least significant 64 bits
(e.g. using asUintN). The JSHeapBroker is extended to provide access to the
BigInt's least significant digit during concurrent compilation. The BigInt
context (required to introduce correct conversions) is recognized in the
RepresentationChanger by either the output type propagated downward or the
TypeCheckKind propagated upward. This is necessary, because the TypeCheckKind
may only be set by nodes that may potentially deopt (and sit in the effect
chain). This is the case for SpeculativeBigIntAdd, but not for BigIntAsUintN.
This CL contains a simple fix to prevent int64-lowered BigInts to flow into
state values as the deoptimizer cannot handle them yet. A more sophisticated
solution to allow the deoptimizer to materialize truncated BigInts will be
added in a following CL.
Bug: v8:9407
Change-Id: I96a293e9077962f53e5f199857644f004e3ae56e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1684183
Commit-Queue: Nico Hartmann <nicohartmann@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62665}
This CL adds the --assert-types flag to d8, which is intended to
insert additional runtime checks after typed nodes, verifying the
validity of our typing rules. So far, only range types are checked.
Thanks to Neil Patil for suggesting something similar.
R=neis@chromium.org, tebbi@chromium.org
Change-Id: I5eb2c482235ec8cd07ee802ca7c12c86c2d3dc40
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678372
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62664}
The alignment should be 3 (i.e. 8 bytes), but was specified as 2 (i.e. 4
bytes).
Bug: v8:9425
Change-Id: I0beb09df25fe0281ed604909e894afd804f5411e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1693836
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62657}
With lazy feedback allocation and bytecode flushing we need to call
%PrepareFunctionForOptimize before we call %OptimizeFunctionOnNextCall/
%OptimizeOsr. This cl:
1. Adds an additional state in pending optimized table to check if the
optimization was triggered manually.
2. Changes the compilation pipeline to delete the entry from pending
optimized table only if the optimization was triggered through
%OptimizeFunctionOnNextCall / %OptimizeOsr.
3. Adds a check to enforce %PrepareFunctionForOptimize was called.
4. Adds a new run-time flag to only check in the d8 test runner. We
don't want this check enabled in other cases like clusterfuzz that doesn't
ensure %PrepareFunctionForOptimize is called.
Bug: v8:8394, v8:8801, v8:9183
Change-Id: I9ae2b2da812e313c746b6df0b2da864c2ed5de51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664810
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62653}
