Private getters and setters are not implemented in v8 and are skipped
already.
Bug: v8:9430
Change-Id: Id59c0757d90ab94b828e5fc7c254d6f209796eea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1702242
Auto-Submit: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62722}
The context was not set during streaming compilation.
The initial upload is the original CL and patch set 1 is the fix.
Original CL:
> [wasm] Compile JS to WASM wrappers asynchronously
>
> R=mstarzinger@chromium.org, ahaas@chromium.org
>
> Bug: v8:9231
> Change-Id: I9e18073bbe25bf8c9c5f9ace102316e6209d0459
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669699
> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62672}
R=mstarzinger@chromium.org, ahaas@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Bug: v8:9231
Change-Id: I61fc11a6de54cc6e93f3600487a89fa5d2350f0e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701850
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Auto-Submit: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62721}
If the lookup of the resolve property on the constructor throws, we
need to call IteratroClose before rejecting the promise.
Bug: v8:9431
Change-Id: Idb33ffe09d339723ef0cd2469335598ab27b49bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701857
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62720}
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 --concurrent-inlining is on, run bytecode analysis for all relevant
functions at serialization time, and store the results in the broker.
Change bytecode analysis such that running it for OSR produces information
that subsumes the non-OSR case. This lets us avoid doing and storing two
analyses for the top-level function in case we do OSR and the function
gets inlined into itself.
Bug: v8:7790
Change-Id: I7d5df0b2652e6e5c758c85578e51b4f8d041b0d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690959
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62711}
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}
We had both jump slots and lazy compile slots in the same table. This
increases the space per slot to the maximum of the two, even though we
often do not use lazy compilation and could have smaller jump slots.
This CL splits the two into two separate tables. The lazy compile table
will only be created on demand, and will never be patched.
The jump table now only contains jumps, and is more compact (which
might improve performance because of improved locality).
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: Ie182873a1ec612f71d1b54447021a9a8f8ca59db
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698393
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62707}
According to the specification, class-specific {operator new} and
{operator delete} should be static methods. Interestingly, if the
{static} keyword is missing, the methods are implicitly static anyway.
This is confusing, so this CL adds the {static} keywords explicitly.
It also removes the redundant {Malloced::New} and {Malloced::Delete}
methods.
R=mlippautz@chromium.org
Bug: v8:9396
Change-Id: I1db7c87b816567cc1a9153d0b18e3dd4ae81dd6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700080
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62703}
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}
...from the Store constructor/destructor. They were preventing embedders
from using several Stores with overlapping but non-nested lifetimes.
Without Isolate::Enter, such use cases are supported; the only consequence
is that Isolate::Current will not work and therefore must not be called;
but it is deprecated and not called from the Wasm C API anyway.
Change-Id: I65eda00243126e189febb0fd8b38a953c4ee078f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698387
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62692}
The serializer clears JSFunctions together with feedback vectors
assuming that there is one to one correspondence between them.
That does not work in the case when there are multiple JSFunctions
sharing the same feedback vector. This patch ensures that all such
JSFunctions are properly cleared.
Bug: v8:7857
Change-Id: Ie441089e12bda5a8be7f9bed90f7be9499938609
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698383
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62673}
Everyone was getting a copy of this through debug.h.
Bug: v8:9396
Change-Id: I5189cb4bf27a3381768b0be479d7b3d60dec20bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695472
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62670}
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}
Even though this is not spec'ed yet, it's good to have an implementation
so that we can use clusterfuzz on it.
I changed the parameter order (hopefully) everywhere to
(table_dst_index, table_src_index, ...). This corresponds to the
(dst, src, ...) parameter order for the entry indices.
R=binji@chromium.org
Bug: v8:7581 chromium:980475
Change-Id: I2fb36ffd4bb2f2be5b22c8366732295fa6759236
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1698386
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62661}
This is a reland of https://crrev.com/c/v8/v8/+/1692366. The original
change was reverted because it broke some blink tests. This will be
landed after suppressing them:
https://crrev.com/c/chromium/src/+/1695541
Make native errors serializable.
The implementation is mostly straightforward, but there is one
exception: the stack property. Although the property is not specified,
the spec for error cloning asks us to preserve the property if
possible. This implementation serializes the property only when it is
a string, and otherwise ignores it.
Spec: https://github.com/whatwg/html/pull/4665
Intent-to-Ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/f8JngIi8qYs
Bug: chromium:970079, v8:9462
Change-Id: Ibf012754f30237f6b5acf119ef834e73727a230f
Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695202
Auto-Submit: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62659}
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}
Even though this is not spec'ed yet, it's good to have an implementation
so that we can use clusterfuzz on it.
R=binji@chromium.org
Bug: v8:7581
Change-Id: I323625322e5240dc6ac224dce8a1f1f7f6070758
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695478
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62656}
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}
GetOwnPropertyNameTryFast uses ENUMERABLE_STRINGS filter to trigger fast
path in KeyAccumulator::GetKeys conditionally when all properties on the
receiver are enumerable. It is not easy to verify if all properties are
enumerable and the current check is incorrect in some cases.
For ex: when we have non-enumerable properties when we have elements on
the receiver. This cl removes this try_fast path from the builtin. This
could impact performance. The long term fix for this would be to fix
KeyAccumulator::GetKeys to use fast path for more cases.
Bug: chromium:977870
Change-Id: Iecde730739c2c452ffa0d893d0d1b3612a45d1b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1679499
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62649}
Reverse specialization of https://chromium-review.googlesource.com/c/v8/v8/+/1684075.
Again, it skips over Tagged to save some instructions.
Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:7703
Change-Id: I7fc50e0d8eebfef7a1ba02ce3d687ff808f30680
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1693007
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62645}
In the atomics stress, the search for sequential sequences creates
lots of new WebAssembly.Memory objects. This memory pressure is not
central to this test, so reuse the same memory to make them less
flaky.
R=mstarzinger@chromium.org
Change-Id: I8d135e7b82d572cb1df38f37a4e2f6393f6b2e05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1697247
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62644}
This adds support for properly importing {WebAssembly.Function} objects
that were constructed in JavaScript and just wrap a JavaScript callable.
R=ahaas@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: I00e01db0d85b83d405eb28517d00fba62c253985
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690949
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62641}
Add a bit on the isolate which indicates that the stack is currently
not iterable for the SafeStackFrameIterator.
This is needed during deoptimization, when we do a fast C call without
a return address on the stack, meaning we can't iterate the stack
frames.
Re-enable DeoptAtFirstLevelInlinedSource which is fixed by this CL.
Bug: v8:9057
Change-Id: I76379a2dd38023be7e6f5153edeb1f838e9ac4d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1688049
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62634}
This fixes a corner-case where a {WasmExportedFunction} that represents
a re-export of a JavaScript callable from another module was identified
correctly, but not all corner-cases were correctly covered. Concretely
we failed to check for function signatures incompatible with JavaScript.
R=ahaas@chromium.org
TEST=mjsunit/regress/wasm/regress-9447
BUG=v8:9447
Change-Id: Ia6c73c82f4c1b9c357c08cde039be6af100727d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690941
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62632}
