This is a reland of 79398ab09d
Original change's description:
> [wasm] Further reduce the size of WasmCode
>
> Also, save dynamic allocations (plus their memory overhead).
> This is realized by storing the relocation information, source position
> table, and protected instruction information together in one "metadata"
> byte array.
> For each of the three components, we just store their size, such that
> the accessors can return the respecitive {Vector} views as before.
>
> This makes each WasmCode object 24 bytes smaller on 64-bit
> architectures. It also saves a few more bytes per code object because
> less padding is needed for the individual allocations, and each dynamic
> allocation comes with some constant memory overhead.
>
> Since the protected instructions will just be stored in a byte array
> now, some APIs are refactored to just return that byte array directly
> (instead of an array of {ProtectedInstructionData}). This also
> simplifies serialization and deserialization, and will allow for
> switching to a more compact representation in the future.
>
> Drive-by: Add some more checks to {Vector::cast} to protect against
> undefined behaviour.
>
> R=ahaas@chromium.org
>
> Bug: v8:10254
> Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66596}
Tbr: ahaas@chromium.org
Bug: v8:10254
Change-Id: Idcdcb4f13c3eb7a3f7fb5ef8a1229103ca0ae975
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089934
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66598}
This reverts commit 79398ab09d.
Reason for revert: Makes UBSan unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10186
Original change's description:
> [wasm] Further reduce the size of WasmCode
>
> Also, save dynamic allocations (plus their memory overhead).
> This is realized by storing the relocation information, source position
> table, and protected instruction information together in one "metadata"
> byte array.
> For each of the three components, we just store their size, such that
> the accessors can return the respecitive {Vector} views as before.
>
> This makes each WasmCode object 24 bytes smaller on 64-bit
> architectures. It also saves a few more bytes per code object because
> less padding is needed for the individual allocations, and each dynamic
> allocation comes with some constant memory overhead.
>
> Since the protected instructions will just be stored in a byte array
> now, some APIs are refactored to just return that byte array directly
> (instead of an array of {ProtectedInstructionData}). This also
> simplifies serialization and deserialization, and will allow for
> switching to a more compact representation in the future.
>
> Drive-by: Add some more checks to {Vector::cast} to protect against
> undefined behaviour.
>
> R=ahaas@chromium.org
>
> Bug: v8:10254
> Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66596}
TBR=jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,tebbi@chromium.org
Change-Id: Id80aa82cfce8942879031032b322ee66855b5600
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10254
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089933
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66597}
Also, save dynamic allocations (plus their memory overhead).
This is realized by storing the relocation information, source position
table, and protected instruction information together in one "metadata"
byte array.
For each of the three components, we just store their size, such that
the accessors can return the respecitive {Vector} views as before.
This makes each WasmCode object 24 bytes smaller on 64-bit
architectures. It also saves a few more bytes per code object because
less padding is needed for the individual allocations, and each dynamic
allocation comes with some constant memory overhead.
Since the protected instructions will just be stored in a byte array
now, some APIs are refactored to just return that byte array directly
(instead of an array of {ProtectedInstructionData}). This also
simplifies serialization and deserialization, and will allow for
switching to a more compact representation in the future.
Drive-by: Add some more checks to {Vector::cast} to protect against
undefined behaviour.
R=ahaas@chromium.org
Bug: v8:10254
Change-Id: I81ca847023841110e3e52cc402fcb0349325d7af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078545
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66596}
This fixes a non-determinism issue caused by the cache being full.
Depending on the non-deterministic value of the handles in HeapConstant
nodes, different cache entries would be overwritten in this case.
The old implementation of NodeCache had a fixed limit, overwriting
entries when the cache is full. This behavior didn't really make sense,
but the hand-written hash map implementation couldn't handle arbitrary
numbers of hash collisions, so removing the limit wasn't an option either.
Thus this CL just replaces the custom hash map with a normal
std::unordered_map, that is, a ZoneUnorderedMap.
Bug: chromium:1046815
Change-Id: I95269f2b1068eb9dfe3ee2ab5cca1cb460bc8fa3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087405
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66592}
Optimizes InstructionSelector::AddInputsToFrameStateDescriptor by
taking advantage of SparseInputMask data structure to more quickly
handle empty inputs and insert all the OptimizedOut entries in one go.
The number of empty inputs is now determined using CountTrailingZeros
rather than iterating over them one at a time.
Gives a 9% improvement to SelectInstructions runtime call stat for
Octane in turboprop.
Bug: v8:10051
Change-Id: Ib13d6f9644b4c89ba0546a19fe0ed623d69fec99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037443
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66591}
This is a reland of 9325397812
Original change's description:
> Use context of then function for PromiseResolveThenableJob
>
> When a microtask is executed, we need to use an appropriate,
> non-detached Context for its execution. Currently with
> PromiseResolveThenableJobs [1], the Context used is always drawn from
> the realm of the Promise constructor being used. This may cause
> non-intuitive behavior, such as in the following case:
>
> const DeadPromise = iframe.contentWindow.Promise;
> const p = DeadPromise.resolve({
> then() {
> return { success: true };
> }
> });
> p.then(result => { console.log(result); });
>
> // Some time later, but synchronously...
> iframe.src = "http://example.com"; // navigate away.
> // DeadPromise's Context is detached state now.
> // p never gets resolved, and its reaction handler never gets called.
>
> To fix this behavior, when PromiseResolveThenableJob is being queued up,
> the `then` method of the thenable should be used to determine the
> context of the resultant microtask. Doing so aligns with Firefox, and
> also with the latest HTML spec [2][3].
>
> This change is analogous to CL 1465902, which uses the realm of the
> reaction handlers to determine the Context PromiseReactionJobs run in.
>
> [1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
> [2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
> [3]: https://github.com/whatwg/html/pull/5212
>
> Bug: v8:10200
> Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66507}
Bug: v8:10200
Change-Id: I5af003a06c60b0c8cd19de47f847a947d40d046c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2082109
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66586}
This patch rolls v8 to the latest Perfetto revision. Since Perfetto has
changed the way the GN protobuf integration works, we need to make some
corresponding changes in V8.
Bug: chromium:639003
Change-Id: I263c591560503c9779bbab3ec266cfb2708fc51f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2085175
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Sami Kyöstilä <skyostil@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66583}
When an empty class is nested inside a class with private instance
methods, like this:
class Outer {
constructor() {}
#method() {}
factory() {
class Inner {
constructor() { }
}
return Inner;
}
run(obj) {
obj.#method();
}
}
The bytecode generator previously generate private brand
initialization for the constructor of Inner by mistake,
because during scope chain serialization/deserialization,
the outer scopes of Inner and factory() are not allocated
or serialized (as they are empty). In the eyes of the bytecode
generator, it then appeared as if Outer is the direct outer
scope of Inner's constructor.
In order to work around this information loss, in this patch
we rely on SharedFunctionInfo instead of the Context/ScopeInfo
chain to maintain the information about private brand initialization.
This is done by shrinking expected_nof_properties to 8 bits and
freeing 8 bits for a second bitfield on the SFI.
Design doc: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit#
Bug: v8:9839, v8:8330, v8:10098
Change-Id: I4370a0459bfc0da388052ad5a91aac59582d811d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056889
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66575}
Remove Isolate parameters from some dictionary methods, and change
others to use ReadOnlyRoots instead, to prepare for Isolate
templatization in a future patch.
One small side-effect is that the global dictionary's property cell's
dependent code deoptimization has to dynamically get the Isolate when
it needs to actually mark code for deoptimization, for method signature
consistency. Given that this is the slow path anyway, it shouldn't
matter.
Bug: chromium:1011762
Change-Id: I707de9a74ca3b30423a1e5830a10729d6a404786
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080369
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66574}
Example can be inspector tests.
Bug: v8:10264
Change-Id: I996bb68d0f36920568a04f93cd8c1256a4f41a96
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070912
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66572}
Move the recently introduced extra check for 32-bit platforms so
that it covers all code paths that would be hit by custom/future
memory limit settings.
Bug: chromium:1057094
Change-Id: I5e2217a24578ee82c7bfa753b7d5dcd3d00e1b7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083300
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66568}
Report the total size of global handles in GetHeapStatistics as well.
This size includes used and free global handles.
Change-Id: I08c0647d993a810a37ae9f332732de9551b5ea8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083020
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66562}
The scope disables garbage collection and should be only used in
heap, deserializer, isolate bootstrap, and testing.
Change-Id: Ide95926ef32fd9362cd9134e883e1bd626cc3b11
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083292
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66557}
This is a reland of c6c9d4bf1b
Original change's description:
> Update unicode-regexp-ignore-case-noi18n expectations
>
> There appear to be one or several bugs in noi18n mode such that
> expectations in this test are no longer met. This CL updates
> expectations to the current behavior and re-enables the test so we at
> least preserve coverage in the other cases.
>
> The behavior in question should be investigated in the future
> (low priority).
>
> Bug: v8:10120
> Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66524}
Bug: v8:10120
Change-Id: Ib2ee68e26c2aebe2eeab3ec9f7bc263fd79f3773
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083291
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66550}
The spec was changed in February TC39 to make ToInteger always normalize
-0 to +0. This only observably affects Atomics.store.
Bug: v8:10271
Change-Id: I0e8f6c35cef982eae242cf6619f6f24fa75b1759
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076509
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66543}
Some opcodes are introduced in V8 for prototyping, and performance
measurements that are not officially a part of the current SIMD proposal
but may be included in future, gate these by a separate flag.
Change-Id: Icc6a9e89c6196c8ff144d2e0193d707e1f60c38b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079539
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66542}
This is a reland of 25d16574f8
Changes from original: replaced slow test with fast test
Original change's description:
> [runtime] Improve handling of enumeration index on global dictionary
>
> Bug: chromium:1056054
> Change-Id: Ie1f2da98bc54a2ad5189cbe2ee1686fe1ef7019a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2079035
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#66504}
Bug: chromium:1056054
Change-Id: I45b9a096b1e37bf1dc5e792f106cdfadd47fabf9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2080855
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66535}
This reverts commit c6c9d4bf1b.
Reason for revert: Fails on noi18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/30737
Original change's description:
> Update unicode-regexp-ignore-case-noi18n expectations
>
> There appear to be one or several bugs in noi18n mode such that
> expectations in this test are no longer met. This CL updates
> expectations to the current behavior and re-enables the test so we at
> least preserve coverage in the other cases.
>
> The behavior in question should be investigated in the future
> (low priority).
>
> Bug: v8:10120
> Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66524}
TBR=jkummerow@chromium.org,jgruber@chromium.org
Change-Id: I960b90fe3679ef4c04782ca9ac9b91454e636dbb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10120
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083024
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66525}
There appear to be one or several bugs in noi18n mode such that
expectations in this test are no longer met. This CL updates
expectations to the current behavior and re-enables the test so we at
least preserve coverage in the other cases.
The behavior in question should be investigated in the future
(low priority).
Bug: v8:10120
Change-Id: Ib7c9a18133a386e6e39ee54d68ce4106d9b28c84
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081815
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66524}
In the past we've used the isolate argument to signal whether we were
in unicode mode (nullptr) or not (the real isolate). This is no longer
needed, and in fact breaks no-i18n mode which always expects to have a
real isolate.
Bug: v8:10120
Change-Id: I2f848c4ff8c2ff0e9b84278cbcdf3c3670e44e58
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081816
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66520}
Remove OffThreadHandle, HandleOrOffThreadHandle, and HandleFor, and
make the OffThreadIsolate allocate "real" Handles. Rather than using
the main-thread Isolate's handle scopes, these off-thread Handles are
backed by a Zone, which is tied to the lifetime of the nearest
OffThreadHandleScope. Eventually, we'll likely want to merge the
implementation of OffThreadHandleScope and HandleScope, but currently
the latter is too tightly coupled to the main thread to do so.
Bug: chromium:1011762
Change-Id: I2a6361931fe3f90a7bef4cc28ee42155fa8d062f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071865
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66516}
We can make better inlining decisions in TurboFan if the CallIC will
provide the feedback that it's seen multiple closures that share the
same SharedFunctionInfo. This is not difficult to do, and it fixes
some frustrating performance cliffs.
Thanks to Bmeurer@chromium.org for the prototype CL, rebased from his
project a year ago.
Bug: v8:2206, v8:10100
Change-Id: I4248145ea67216f9a23efa175bbe90e7a9ee0ec4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2054100
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66512}
This reverts commit 9325397812.
Reason for revert: Causing blink layout failures. See
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux%20Future/2684
Original change's description:
> Use context of then function for PromiseResolveThenableJob
>
> When a microtask is executed, we need to use an appropriate,
> non-detached Context for its execution. Currently with
> PromiseResolveThenableJobs [1], the Context used is always drawn from
> the realm of the Promise constructor being used. This may cause
> non-intuitive behavior, such as in the following case:
>
> const DeadPromise = iframe.contentWindow.Promise;
> const p = DeadPromise.resolve({
> then() {
> return { success: true };
> }
> });
> p.then(result => { console.log(result); });
>
> // Some time later, but synchronously...
> iframe.src = "http://example.com"; // navigate away.
> // DeadPromise's Context is detached state now.
> // p never gets resolved, and its reaction handler never gets called.
>
> To fix this behavior, when PromiseResolveThenableJob is being queued up,
> the `then` method of the thenable should be used to determine the
> context of the resultant microtask. Doing so aligns with Firefox, and
> also with the latest HTML spec [2][3].
>
> This change is analogous to CL 1465902, which uses the realm of the
> reaction handlers to determine the Context PromiseReactionJobs run in.
>
> [1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
> [2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
> [3]: https://github.com/whatwg/html/pull/5212
>
> Bug: v8:10200
> Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
> Commit-Queue: Timothy Gu <timothygu@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66507}
TBR=verwaest@chromium.org,timothygu@chromium.org,syg@chromium.org
Change-Id: I81737750f8b369567ba586c5a2cfb489836b7e74
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10200
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2081091
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66510}
When a microtask is executed, we need to use an appropriate,
non-detached Context for its execution. Currently with
PromiseResolveThenableJobs [1], the Context used is always drawn from
the realm of the Promise constructor being used. This may cause
non-intuitive behavior, such as in the following case:
const DeadPromise = iframe.contentWindow.Promise;
const p = DeadPromise.resolve({
then() {
return { success: true };
}
});
p.then(result => { console.log(result); });
// Some time later, but synchronously...
iframe.src = "http://example.com"; // navigate away.
// DeadPromise's Context is detached state now.
// p never gets resolved, and its reaction handler never gets called.
To fix this behavior, when PromiseResolveThenableJob is being queued up,
the `then` method of the thenable should be used to determine the
context of the resultant microtask. Doing so aligns with Firefox, and
also with the latest HTML spec [2][3].
This change is analogous to CL 1465902, which uses the realm of the
reaction handlers to determine the Context PromiseReactionJobs run in.
[1]: https://tc39.es/ecma262/#sec-promiseresolvethenablejob
[2]: https://html.spec.whatwg.org/C/#enqueuejob(queuename,-job,-arguments)
[3]: https://github.com/whatwg/html/pull/5212
Bug: v8:10200
Change-Id: I2312788eeea0f9e870c13cf3cb5730a87d15609e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071624
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66507}
Previously, our Torque definition of JSArrayBuffer included only the
first two fields. This allowed access to those two fields, but was
somewhat confusing and obviously didn't let Torque code access the
other fields. This change:
- Completes the JSArrayBuffer layout definition;
- Moves the associated bitfield struct definition to Torque;
- Moves a couple of JSArrayBuffer macros to Torque;
- Adds a reducer case so that the code generated using these new macros
is not worse than what was generated previously.
Change-Id: Ib19c3ba789a33801fa9d0d064cd21d62a1e03e30
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2053769
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66503}
There were a few places that still checked against the limit for
initial memory size rather than the limit for memory size after
growth (which was recently separated from the former).
Bug: v8:7881
Change-Id: Id17d86e2f7a5dfa4f1dd35153b0cefc01f72ed33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078574
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66496}
Port 6cd28b522a
Original Commit Message:
Added implementations for ia32, arm, arm64.
mips/mips64 will be committed in separate CL once the build is green
again in order not to stall this CL with the supported architectures.
compilation by using alternative temp register for x64.
macro assemblers.
R=ecmziegler@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N
Change-Id: Ib08e31dfa11f0254c7888ce17dd27e7d0154c752
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078898
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66490}
Added implementations for ia32, arm, arm64.
mips/mips64 will be committed in separate CL once the build is green
again in order not to stall this CL with the supported architectures.
Drive-by: Fixed issues with kScratchRegister being overwritten in case of RegExp
compilation by using alternative temp register for x64.
Drive-by: Added missing NoRootArrayScope to ia32, arm and arm64 RegExp
macro assemblers.
R=clemensb@chromium.orgR=petermarshall@chromium.orgR=jgruber@chromium.org
Bug: chromium:1045860
Change-Id: I716d852b9bf780ae7b8d61376c6505dd3af96a50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071866
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66482}
Most function signatures are created once and never changed. Hence pass
them as const pointer. This makes it clear in function signatures that
these parameters will not be modified.
This also avoids a few ugly const_casts where we were passing pointers
to constexpr FunctionSigs via non-const pointers.
R=jkummerow@chromium.org
Bug: v8:10155
Change-Id: Ieb658ab5582bff276f76babdaf7ddb8f72bd4790
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072739
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66478}
This is a reland of 7d1f95d6e4
The reland fixes a performance issue in that we incorrectly marked
every pattern containing a backslash as needing to be escaped,
resulting in a new string allocation instead of reusing the existing
string.
Original change's description:
> [regexp] Correctly escape a backslash-newline sequence
>
> When printing the source string, a backslash-newline sequence ('\\\n',
> '\\\r', '\\\u2028', '\\\u2029') should be formatted as '\n', '\r',
> '\u2028', '\u2029', respectively. Prior to this CL it was formatted as
> a backslash followed by the literal newline character.
>
> Bug: v8:8615
> Change-Id: Iac90195c56ea1707ea8469066b0cc967ea87fc73
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016583
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Auto-Submit: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#65986}
Bug: v8:8615,chromium:1046678
Change-Id: I5d75904f1ea543ec679649668e54749821116442
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074159
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66476}
This reverts commit 4dc1fb4e04.
Reason for revert: the regression from the original change was likely due to unlucky factors like code alignment.
Original change's description:
> Revert "[torque] Support bitfield structs stored within Smis"
>
> This reverts commit e5e4ea962e.
>
> Reason for revert: mysterious performance regression chromium:1052756
>
> Original change's description:
> > [torque] Support bitfield structs stored within Smis
> >
> > This change moves the definition of the bits stored in DebugInfo::flags
> > to Torque, and updates the only Torque usage of that field to use more
> > natural syntax. This is intended as an example of common patterns found
> > in various other classes. Several supporting changes are required:
> >
> > 1. Add a new type representing a bitfield struct stored within a Smi. It
> > is currently called SmiTagged, but I'm open to suggestions.
> > 2. Add an enum-style output for Torque bitfield structs whose bitfields
> > occupy only one bit each.
> > 3. Add a new case to MachineOperatorReducer that makes the generated
> > code for IncBlockCounter match with what was generated before this
> > change.
> > 4. Add support for reporting these bitfields in the postmortem debugging
> > API. The format matches existing bitfields but with an offset value
> > that includes the SMI shift size.
> >
> > Bug: v8:7793
> > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#66182}
>
> Bug: chromium:1052756, v8:7793
> Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66349}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1052756, v8:7793
Change-Id: I6087928aa14c8551ebd294513bd8d6ffa402a0d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2070635
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66465}
Before: running different suites is removing non-related master data
After: different suites have separate master data files
Change-Id: Iab46d663fdf2a1d709aeb7da77a443c2ed1bdcc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2071870
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Marcin Wiącek <marcin@mwiacek.com>
Cr-Commit-Position: refs/heads/master@{#66453}
This reverts commit b12ba06edf.
Reason for revert:
After further discussion we decided to stick with fdlibm.
Original change's description:
> [builtins] stop using imprecise fdlibm pow
>
> This CL reinstates the old pow implementation which calls out to the
> system implementation of pow.
>
> Bug: v8:9622
> Change-Id: I3df997888ced3fb8b5bd4b810098e967649aaa55
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774898
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66303}
TBR=yangguo@chromium.org,neis@chromium.org,hpayer@chromium.org,me@gus.host
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9622
Change-Id: I941f70c7432cd2fab86e0eadcb2e1a9ec8195e91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072746
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66452}
Added a type field to elements to distinguish anyref, funcref and
nullref elements and do a proper type checking at compile time as
the spec requires.
R=ahaas@chromium.org
Change-Id: I31be7aa1170439859ca7ec5e20aabb2720c290b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069330
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66448}
