This CL migrates BaselineData::baseline_code field and
InterpreterData::interpreter_trampoline field to CodeT.
Bug: v8:11880
Change-Id: Ibd202f0dcd4266e5b98aa5c46754ba8a4fadff43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968415
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75233}
Currently, we have two different classes for switching the WebAssembly
generated code space to writable (e.g., before patching jump tables, or
when adding or removing code): `CodeSpaceWriteScope` (with the macro
`CODE_SPACE_WRITE_SCOPE`) and `NativeModuleModificationScope`.
The former was introduced for Apple Silicon ARM64 hardware ("Apple M1"),
which uses `MAP_JIT` + `pthread_jit_write_protect_np()` to change memory
permissions. The latter uses either Intel PKU (aka. memory protection
keys) to switch permissions (fast and thread-local, like on M1), and
alternatively `mprotect()`, on systems that do not have PKU support.
Since both classes serve the same purpose just with different
implementations on different platforms, we want to merge them in
follow-up CLs. As a first step, here we align all uses of
`CODE_SPACE_WRITE_SCOPE` with existing `NativeModuleModificationScope`s.
The two had diverged due to optimization work, where we moved
`NativeModuleModificationScope`s around (pulling them out of loops and
across function boundaries) to lower the amount of mprotect switches.
This should have none, or at best a very small positive performance
impact on Apple M1, since we now also switch less often (even though
switching should be very cheap). In terms of security, this in theory
makes the code space writable for longer time spans, but this is
probably not a large effect because
(1) we often moved the scope outside of loops, where it was open for
every iteration anyway, or
(2) in some cases a CODE_SPACE_WRITE_SCOPE was open somewhere on the
call stack already.
R=jkummerow@chromium.orgCC=clemensb@chromium.org
Bug: v8:11714
Change-Id: Id8744429e1183e118ab5e078750d294a99c9dce0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968946
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Daniel Lehmann <dlehmann@google.com>
Cr-Commit-Position: refs/heads/master@{#75230}
- Add tests and fix Chunk calculations in Timeline class
- Cache DOM nodes directly as properties in TimelineTrackBase
- Keep track of last focused entry in timeline tracks and reuse it
to position the tooltip when the view is locked
Bug: v8:10644
Change-Id: I356dcf7eed220df89f6a7ff926f00f78b119160e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968943
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75224}
This reverts commit 9caf26b94c.
Reason for revert: Needed to be changed to kNumCallerSavedDoubles
Original change's description:
> S390: fix byte count when pushing/popping doubles
>
> `NumRegs` runs a `population count` and must be used with
> a `RegList` and not with a regular integer value.
>
> kCallerSavedDoubles is a regular integer and should be used as is.
>
> Change-Id: Id9535134ad4ea02bebed9b506012084d93acc2c2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2965159
> Reviewed-by: Junliang Yan <junyan@redhat.com>
> Commit-Queue: Milad Fa <mfarazma@redhat.com>
> Cr-Commit-Position: refs/heads/master@{#75213}
Change-Id: Ifae6ee99b698f5a1f68a7c42cda1743fd1cbf0d7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2969623
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#75223}
The test was a bit out-dated, the expected file did not match the test
or the data delivered by V8 anymore. However, all the expected data was
available, so I just adjusted the test accordingly.
R=clemensb@chromium.org
Bug: v8:10356
Change-Id: I1d94f2a295038a4320e07706d46258a278a6dee5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968410
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75222}
This isn't used outside of tests, so let's just remove it.
Change-Id: I06b7ec11911fd8ebc3bbabcba16d0c2a3fafddab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968413
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75220}
At the moment deserialization happens synchronously on the main thread.
This is fine at the moment because deserialization is fast. However,
future refactorings may affect deserialization time, and may force us
to deserialize in the background. This CL adds a timer to monitor
deserialization time, so that we get a signal if deserialization time
regresses.
R=clemensb@chromium.org
Bug: v8:11862
Change-Id: I18b52c19106b92158cd986492926a24d0d57e6ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966389
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75218}
This also removes intrinsics that were just used in tests. It keeps
InlineIncBlockCounter for now because it's a less straightforward.
Change-Id: I77e55d7a746294892d0fd7ab577ebf8eb42f1f08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953195
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75217}
Replace all uses of NewArray/DeleteArray with new[]/delete[] in
utils/vector.h which allows removing the dependency on
utils/allocation.h.
As a result allocation failures here will not call
FatalProcessOutOfMemory any more, but it's likely it wouldn't have been
called anyway.
Also adds some missing includes that were being previously being brought
in via vector.h depending on allocation.h.
Bug: v8:11879
Change-Id: I5055b49fad0d06642a9bd3eebb93a6a0e4acca60
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968405
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75216}
MemoryChunkLayout::MaxRegularCodeObjectSize() can be cached in a
global variable on process initialization. This should help to increase
code object allocation performance, since this method was called on
each code object allocation.
Bug: v8:11891
Change-Id: I870bd37202370aec89ef2db24264e363099bf8a0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966387
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75215}
WebAssembly.Exception is the static representation of a wasm exception.
It holds the signature and the tag of the exception, can be imported and
exported from a wasm module, and will eventually allow inspecting a
wasm-thrown exception from JS.
R=clemensb@chromium.org
Bug: v8:8091
Change-Id: Ided352777e1217e6f873b84a2fc21c3acf59ff6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966384
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75214}
`NumRegs` runs a `population count` and must be used with
a `RegList` and not with a regular integer value.
kCallerSavedDoubles is a regular integer and should be used as is.
Change-Id: Id9535134ad4ea02bebed9b506012084d93acc2c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2965159
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#75213}
Mark the write of the property as relaxed atomic. The compiler thread
is examining the value. It is fine if the value is stale or new, we
simply need to let TSAN know we are aware of the race.
BUG=v8:11896
Change-Id: I42505a6e12c7eb3c1ef8d9376d7a420567646d62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968403
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75209}
The PropertyArray may store the hash of it's parent object. This hash
can be installed at various points. Meanwhile, the background compiler
thread inspects the length field.
BUG=chromium:1220974
Change-Id: I7b13fd4546fb48e649fcbf67dee02d7c668393f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967471
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75208}
This CL adds
- CodeT type - an alias for CodeDataContainer or Code depending on
whether the v8_enable_external_code_space is enabled or not,
- a set of conversion functions from CodeT to Code or CodeDataContainer
and back (both in C++ and CodeStubAssembler),
- masm support for calling/tailcalling via CallDataContainer which
contain the code entry point address,
- masm support for calling/tailcalling via CodeT.
Bug: v8:11880
Change-Id: Ib36f4c6db69ec49aaea29412647e59ada95da19b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967463
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75207}
This finishes the TSAN support for loads as we do not use movb or movw
to load from memory
Bug: v8:7790, v8:11600
Change-Id: I3c319da95c24cfa03f4de2367e007fd4cf7dd355
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2953321
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75204}
Adds support to webassembly and enables it by default.
Adds wee8 target.
We can compile without wasm with:
`bazel build :d8 --no//:v8_enable_webassembly`
Bug: v8:11234
Change-Id: I90b11eb71aed808005b66e40e37894616d8b1658
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960803
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75200}
Fuzzing found a problem with --turbo-optimize-apply when the
Array.prototype iterator is replaced with a generator function.
We can the issue by installing a protector on the array iterator.
This CL also defines the --turbo-optimize-apply as 'future' to get
more test coverage.
Bug: v8:9974
Change-Id: Id5bc68fde98ea5d1f6a951c4381ca6283b892632
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966058
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75197}
To enable deallocation of CodeEntry objects after they're no longer
being referenced by an active profile or alive on the heap, replace the
|used| bit with a proper reference count maintained by a CodeMap.
Bug: v8:11054
Change-Id: I3016cdbcbd1b4e8a26c3b1689e968cb2eef8e6d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2965493
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Andrew Comminos <acomminos@fb.com>
Cr-Commit-Position: refs/heads/master@{#75193}
Empty function bodies can actually reach the compiler. We could prevent
this by making this a decoder error instead, but that would be a
redundant check, so we should just remove the DCHECK instead.
R=ahaas@chromium.org
Bug: chromium:1219898
Change-Id: Ie1bed30cee44be9ac42b5f5f980a122c8dc8b2ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966385
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75191}
Add tests for Intl Locale Info API to ensure the return items fit the
type definition in UTS35
Bug: v8:11887
Change-Id: Ie92d80518909df9472ffd887800832a656807b5c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964597
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75190}
The object may have been poisoned again between marking and compaction
through executing pre-finalizers or custom weakness handling of
related objects.
Bug: chromium:1220666, chromium:1056170
Change-Id: Ibba4b42852a2921640d6f3ded473521febb2114f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966386
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75189}
When pushing/popping registers, we need a way in PPC and S390
to detect if Simd registers need to be pushed or not.
On PPC Simd registers are separate from FP registers, hence we
need to push them both. If Simd is not available then we push
an empty space in place of Simd registers.
On S390 the Simd and FP registers are shared. If Simd is available
then we only push them and not the FPs, else we push FP registers
as well as an empty space the size of FPs as the stack needs to look
like as if Simds were saved too.
We also need to check if we are generating builtins or
call is being made at runtime. We cannot use `SupportsWasmSimd128`
when generating builtin as `CpuFeatures` are turned off, so we need
to emit the `if/else` manually for checking the value of
`SupportsWasmSimd128`.
Change-Id: Id149c6578db9c2f92d903fd871d85c648d43ce70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2958963
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/master@{#75188}
In heap-refs.cc, GetOwnFastDataPropertyFromHeap() bottlenecks reading
a fast property. To make it safe to use from the background thread we
need to verify the object didn't shrink, and risk an out of heap
bounds read.
Bug: v8:7790
Change-Id: Idebbe0ffea089bf2a70aa7d611618430169082fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928185
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75186}
This mutex wasn't really used anymore. This should also speed up
code object allocation a bit.
Bug: v8:11888
Change-Id: I8ddc2ecc1aec74e8eb3e2d4b96354c50f3bff350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966382
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75185}
Rather than letting a recursive macro expansion cause a stack overflow
and crash the compiler, this change updates Torque to emit an error as
soon as the recursion is detected. Eventually it would be nice to make
Cast macros a little more magical so they don't require so much human
effort to maintain, but at least this way Torque displays some
information about what went wrong. An example error message (manually
wrapped to 72 character width) follows.
src/builtins/cast.tq:157:10: Torque Error: Recursive macro call to
callable Cast<(class Context | Undefined | Zero)>(implicit class
Context)(Object): (class Context | Undefined | Zero)
src/builtins/cast.tq:758:3: Torque Error: Note: in specialization
Cast<(class Context | Undefined | Zero)> requested here
src/builtins/cast.tq:764:10: Torque Error: Note: in specialization
Is<(class Context | Undefined | Zero), Object> requested here
src/builtins/torque-internal.tq:64:3: Torque Error: Note: in
specialization UnsafeCast<(class Context | Undefined | Zero)>
requested here
src/objects/contexts.tq:75:10: Torque Error: Note: in specialization
ReferenceCast<(class Context | Undefined | Zero), Object> requested
here
src/builtins/iterator.tq:142:16: Torque Error: Note: in specialization
ContextSlot<class Context, class Context, (class Context | Undefined |
Zero)> requested here
Bug: v8:11727
Change-Id: I7b5b1852dee16a6860f593f27783f6b2d9366146
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2965032
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#75184}
