This function tries to determine the number of virtual address bits
available on the current CPU and with that the maximum size of the
userspace address space. On x64, it can be implemented through CPUID.
The result of this function is now used in two ways: first, it limits
the maximum size of the virtual memory cage, currently to a quarter of
the address space. Second, it influences the placement of fake cages,
which are attempted to be placed into the lower half of the address
space so that they are followed by large amounts of (hopefully) unused
but addressable virtual memory in which pages can be allocated.
Bug: chromium:1218005
Change-Id: I0edc5d241d899f16dbc47492fa1534b6aaa4aa13
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220348
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77393}
V8 can fall back to creating a virtual memory cage that does not have
the desired security properties but at least allows V8 to run when
caging is enabled. This API allows the embedder to determine which kind
of cage is being used, for example for metrics collection.
Bug: chromium:1218005
Change-Id: I6988d0a4fce8aeb1361b30fce8c9c2f68f3b92f9
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220343
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77392}
- Anonymous namespaces instead of static functions.
- Comments.
- Reserve enough space in the range ZoneList.
Change-Id: Ie79fda770974796cd590a155dc5fd504472e5bc9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220341
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77391}
The concurrent marker consults the page flags to see if it should skip
objects in the shared heap, and it was missing a SynchronizePageAccess,
causing TSAN false positives.
Bug: v8:12314, v8:12007
Change-Id: I888a68a3eddaa3dfa1644364226010def8d2a9b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219946
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77390}
Scripts are treated as web snapshots if they start with a magic number.
This enables end-to-end web snapshot implementations without changing
the embedders.
Bug: v8:11525
Change-Id: Ib8b098bb8cf0b9f96894009414b1cea7646b60dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218977
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77389}
Tip of tree puts both internalized and in-place-internalizable strings
into the shared heap object cache. But only internalized strings need
to go in there, since we can't have duplicates of those. It's fine to
allocate in-place-internalizable strings in the shared heap each time
a new Isolate is initialized, it'll be deduplicated if it's
internalized eventually.
Bug: chromium:1258918, v8:12007
Change-Id: I0e46b73a5ac3be83d0eaa31915a3a24f47a8c2bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219690
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77388}
Mostly the macro lists, the rest will be moved in a follow-up.
Bug: v8:12207
Change-Id: Iedf48e80f94ac99869c8aa31516cf93f9fc23667
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3209665
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77387}
Consider in-construction keys as live during the final GC pause.
Bug: chromium:1259587
Change-Id: Ia8c05923db6e5827b68b17a51561fbc8b2c4b467
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3221153
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77386}
The purpose of this CL is:
- To include all the logic of this function within the bit case switch.
- To make it more clear what the probabilities for each generated
subtype are.
- To fix bugs where anyref fell back to unsupported types in interpreter
mode.
Bug: v8:11954
Change-Id: Ibc2d487c3fd66ec44a2a4f0eee874c8d3591be52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220347
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77385}
Due to caching issues we will not be able to store host-defined options
directly on the Script anymore. ScriptOrModule can thus no longer be
a i::Script.
NodeJS keeps weak references from ScriptOrModule to their import meta
data. This CL changes ScriptOrModule to be a temporary struct which has
a different lifetime. As a temporary fix until the API is fully updated
we introduce the v8_scriptormodule_legacy_lifetime compile-time flag.
It keeps references to ScriptOrModule alive on the Script to restore the
previous behavior (at an additional memory cost).
Bug: chromium:1244145
Change-Id: I1dc42d25930d7bc4f22ee3c9bba93d89425be406
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211575
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77382}
This is a reland of 3600aabf73
Original change's description:
> ppc: [liftoff] implement AtomicExch and AtomicCmpExch
>
> Change-Id: Ida66b9c42cfb9bd5b59a83188a2dfa0d602d4036
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3192427
> Reviewed-by: Milad Fa <mfarazma@redhat.com>
> Commit-Queue: Junliang Yan <junyan@redhat.com>
> Cr-Commit-Position: refs/heads/main@{#77148}
Change-Id: I84dc2d2c429c1f1646d0b97036ad9baa96961e56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3216042
Commit-Queue: Junliang Yan <junyan@redhat.com>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77381}
We need to check if the index is less than zero and miss to the runtime
if this is so.
Bug: chromium:1257519
Change-Id: I7d22f2765232815120b8baf7b8b83d5b00024375
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218975
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77380}
This is a reland of 1ea76c1397
Disabled the failing test on Fuchsia until its PageAllocator
respects allocation hints.
Original change's description:
> Implement a fake virtual memory cage mechanism
>
> On operating systems where reserving virtual address space is expensive,
> notably Windows pre 8.1, it is not possible to create a proper virtual
> memory cage. In order to still be able to reference caged objects
> through offsets from the cage base on these systems, this CL introduces
> a fake cage mechanism. When the fake cage is used, most of the virtual
> memory for the cage is not actually reserved. Instead, the cage's page
> allocator simply relies on hints to the OS to obtain pages inside the
> cage. This does, however, not provide the same security benefits as a
> real cage as unrelated allocations might end up inside the cage.
>
> Bug: chromium:1218005
> Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
> Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217200
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77367}
Bug: chromium:1218005
Change-Id: I2ed95d121db164679c38085115e8fa92690c057e
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220151
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77378}
Introduces several new runtime mechanics for defining private fields,
including:
- Bytecode StaKeyedPropertyAsDefine
- Builtins StoreOwnIC{Trampoline|Baseline|_NoFeedback}
- Builtins KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic}
- TurboFan IR opcode JSDefineProperty
These new operations can reduce a runtime call per class field into a
more traditional Store equivalent. In the microbenchmarks, this
results in a substantial win over the status quo (~8x benchmark score
for single fields with the changes, ~20x with multiple fields).
The TurboFan JSDefineProperty op is lowered in
JSNativeContextSpecialization, however this required some hacks.
Because private fields are defined as DONT_ENUM when added to the
object, we can't find a suitable transition using the typical data
property (NONE) flags. I've added a mechanism to specify the required
PropertyAttributes for the transition we want to look up.
Details:
New bytecodes:
- StaKeyedPropertyAsDefine, which is essentially StaKeyedProperty
but with a different IC builtin (KeyedDefineOwnIC). This is a
bytecode rather than a flag for the existing StaKeyedProperty in
order to avoid impacting typical keyed stores in any way due to
additional branching and testing.
New builtins:
- StoreOwnIC{TTrampoline|Baseline|_NoFeedback} is now used for
StaNamedOwnProperty. Unlike the regular StoreIC, this variant will
no longer look up the property name in the prototype.
In adddition, this CL changes an assumption that
StoreNamedOwnProperty can't result in a map transition, as we
can't rely on the property already being present in the Map due
to an object literal boilerplate.
In the context of class features, this replaces the runtime
function %CreateDataProperty().
- KeyedDefineOwnIC{Trampoline|Baseline|_Megamorphic} is used by the
new StaKeyedPropertyAsDefine bytecode. This is similar to an
ordinary KeyedStoreIC, but will not check the prototype for
setters, and for private fields, will take the slow path if the
field already exists.
In the context of class features, this replaces the runtime
function %AddPrivateField().
TurboFan IR:
- JSDefineProperty is introduced to represent a situation where we
need to use "Define" semantics, in particular, it codifies that we
do not consult the prototype chain, and the semantics relating to
private fields are implied as well.
R=leszeks@chromium.org, syg@chromium.org, rmcilroy@chromium.org
Bug: v8:9888
Change-Id: Idcc947585c0e612f9e8533aa4e2e0f8f0df8875d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2795831
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#77377}
There's no point in maintaining a separate counter for the size of a
`std::list`. Also changing the type to `size_t` consistently.
Bug: chromium:1257637
Change-Id: I4f938b9888bb09cd1223ae6b6ae1db0fa1181096
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220332
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77376}
Instead, pass a return parameter to store the error message, if any.
Change-Id: Ie71910149271a4268799ee41a8873df51812c505
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218989
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77375}
Rolling v8/build: 64ad2a1..f78b0bd
Rolling v8/buildtools/clang_format/script: 99803d7..99876ca
Rolling v8/buildtools/linux64: git_revision:0153d369bbccc908f4da4993b1ba82728055926a..git_revision:693f9fb87e4febdd4299db9f73d8d2c958e63148
Rolling v8/third_party/aemu-linux-x64: -dh4A1LzldRT2V-3X5pbC7DZsxgQ01JhKIFo6Bx5WP4C..oT0j0p3wnLGyIs4qDcea3sRhW4YKoAhTY2LDWkJ4T4QC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ee3f2f4..876bab7
Rolling v8/third_party/depot_tools: 7cdf142..756e98f
Rolling v8/third_party/icu: 4df07a2..eedbaf7
Rolling v8/third_party/zlib: bffc82b..6da1d53
Rolling v8/tools/clang: 203feb7..c00aa10
Rolling v8/tools/luci-go: git_revision:413d434bd4eee1130614494dfb19f1eba03d71af..git_revision:d1c03082ecda0148d8096f1fd8bf5491eafc7323
Rolling v8/tools/luci-go: git_revision:413d434bd4eee1130614494dfb19f1eba03d71af..git_revision:d1c03082ecda0148d8096f1fd8bf5491eafc7323
Rolling v8/tools/luci-go: git_revision:413d434bd4eee1130614494dfb19f1eba03d71af..git_revision:d1c03082ecda0148d8096f1fd8bf5491eafc7323
TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I465ba638acf2820aba8d5872f87b19f58388ae57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217261
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77374}
This is a reland of 9fe53c4f0b
- Fix data-race by using an atomic for flag_hash;
- Make sure flag_hash != 0
- Initialize flag_hash in V8::InitializeOncePerProcessImpl
- Clear flag_hash in more cases
Original change's description:
> [flags] Skip --random-seed in FlagList::Hash
>
> Node and friends use --random-seed to temporary reset the seed for
> predictable code-cache creation. To allow custom random seeds at runtime
> the flag is reset for encoding the FlagList::Hash in the snapshots.
>
> We will soon disallow changing flags via the API after V8 has been
> initialized. In order to make node work we will exclude --random-seed
> from the FlagList::Hash calculation.
>
> Drive-by-fix:
> * Lazily initialize flag_hash instead of calculating it after every call
> to SetFlagsFromString / EnforceFlagImplications.
> * Simplify hash string source creation since out << flag now includes
> the full flag information
>
> Bug: v8:12309
> Change-Id: I1a168f4702d8c4d160ff12fdbea881731e4ea8b6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218159
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77345}
Bug: v8:12309
Change-Id: I12cd2931d81dc74e07a4da3564e4bf8dd151300a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218981
Commit-Queue: Marja Hölttä <marja@chromium.org>
Auto-Submit: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77373}
Also skip the test-shared-strings/YoungInternalization cctest, which
doesn't make sense when there is no young generation.
Bug: v8:12007
Change-Id: I3006960181a7da681d7318289a6ade6b0f0bf6da
Cq-Include-Trybots: luci.v8.try:v8_linux64_single_generation_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218197
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77371}
https://crrev.com/c/3218150 introduced a bug where we would create a
filler entry without updating the object start bitmap.
Bug: v8:12295
Change-Id: Ic39cea54d2e0e8297fe58eb1e5b22d787874c565
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218066
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77370}
After https://crrev.com/c/3211894 the following error
gets thrown on gcc:
```
error: call to non-'constexpr' function 'uint8_t
v8::internal::LocalHeap::ThreadState::raw() const'
: raw_state_(state.raw()) {}
```
Bug: v8:11708
Change-Id: I6377c95fa38d4b4670f6a513e061f13e349a3212
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3216043
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Milad Fa <mfarazma@redhat.com>
Commit-Queue: Milad Fa <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#77369}
This reverts commit 1ea76c1397.
Reason for revert: The unit test added fails on the Fuchsia bot https://ci.chromium.org/p/v8/builders/ci/V8%20Fuchsia/25976?
Original change's description:
> Implement a fake virtual memory cage mechanism
>
> On operating systems where reserving virtual address space is expensive,
> notably Windows pre 8.1, it is not possible to create a proper virtual
> memory cage. In order to still be able to reference caged objects
> through offsets from the cage base on these systems, this CL introduces
> a fake cage mechanism. When the fake cage is used, most of the virtual
> memory for the cage is not actually reserved. Instead, the cage's page
> allocator simply relies on hints to the OS to obtain pages inside the
> cage. This does, however, not provide the same security benefits as a
> real cage as unrelated allocations might end up inside the cage.
>
> Bug: chromium:1218005
> Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
> Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217200
> Commit-Queue: Samuel Groß <saelo@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77367}
Bug: chromium:1218005
Change-Id: I541bb9656ab2a6a080c2a30d372226fcc5c95391
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219086
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77368}
On operating systems where reserving virtual address space is expensive,
notably Windows pre 8.1, it is not possible to create a proper virtual
memory cage. In order to still be able to reference caged objects
through offsets from the cage base on these systems, this CL introduces
a fake cage mechanism. When the fake cage is used, most of the virtual
memory for the cage is not actually reserved. Instead, the cage's page
allocator simply relies on hints to the OS to obtain pages inside the
cage. This does, however, not provide the same security benefits as a
real cage as unrelated allocations might end up inside the cage.
Bug: chromium:1218005
Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217200
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77367}
assume_aligned allows the caller may assume alignment of the allocation
methods.
Bug: v8:12295
Change-Id: I0c946dd668ae9c0c1d83da7278ad8d87bab96717
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218984
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77366}
... as a result of merging RelocInfo::target_object() with
RelocInfo::target_object_no_host(PtrComprCageBase),
where the cage base is used for accessing compressed embedded pointers.
There are two reasons for this change:
1) the parameterless version used to compute the cage base value from
the host Code object, however, when external code space is enabled
such a base value will not work for non-Code objects, since they
require different cage base for decompressing,
2) when external code space is enabled, there must be no need to embed
compressed Code objects at all because CodeDataContainers must be
used instead.
In addition this CL introduces DCHECKs to enforce (2).
Bug: v8:11880
Change-Id: I5b504f91dea87c2bcaa1165d2dbfaada70cba7be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211998
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77361}
This guarantees that if it's context-allocated, it'll be the first
slot in the context. That in turn allows us to drop a special index on
scope-info pointing at the receiver entry; once we update arguments
object handling to take the receiver possibly being there into
account.
Change-Id: Idfd06cf172e6905b02c8d17a962382e2a9ea0874
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211999
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77360}
We forgot to add statistic reporting for off-thread finalization -- this
needs to be done during the main-thread fix-ups since it can call
embedder callbacks.
Change-Id: I3959a1512166cbdea028799c771f733a6c8a6163
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217198
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77358}
Walking the dominator tree can be slow when that tree is very deep,
and since it's typically done at least once for every BasicBlock,
overall cost is approximately quadratic.
With some (sparse) caching, we can get significant speedups for
very little extra memory consumption.
In the specific function I looked at, tree depth was around 11,500,
and this patch speeds up the Scheduling phase from 42 seconds to 0.2
seconds, while increasing its memory consumption from 113.1 to 113.4
megabytes.
Change-Id: Iaa32d249a30f62269858d090fbd8924d16d3a9f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218157
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77356}
We add support for i31.new, i31.get_u and i31.get_s to the fuzzed module.
Bug: v8:11954
Change-Id: Ic6cdb5ced1b56507083d91e5c0c7f21d59a18acf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218980
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Maria Tîmbur <mtimbur@google.com>
Cr-Commit-Position: refs/heads/main@{#77354}
Rolling v8/build: 64ad2a1..ed0a6d9
Rolling v8/buildtools/clang_format/script: 99803d7..99876ca
Rolling v8/buildtools/linux64: git_revision:0153d369bbccc908f4da4993b1ba82728055926a..git_revision:693f9fb87e4febdd4299db9f73d8d2c958e63148
Rolling v8/third_party/aemu-linux-x64: -dh4A1LzldRT2V-3X5pbC7DZsxgQ01JhKIFo6Bx5WP4C..oT0j0p3wnLGyIs4qDcea3sRhW4YKoAhTY2LDWkJ4T4QC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/ee3f2f4..876bab7
Rolling v8/third_party/depot_tools: 7cdf142..4a06fb5
Rolling v8/third_party/zlib: bffc82b..edc0e06
Rolling v8/tools/luci-go: git_revision:413d434bd4eee1130614494dfb19f1eba03d71af..git_revision:d1c03082ecda0148d8096f1fd8bf5491eafc7323
Rolling v8/tools/luci-go: git_revision:413d434bd4eee1130614494dfb19f1eba03d71af..git_revision:d1c03082ecda0148d8096f1fd8bf5491eafc7323
Rolling v8/tools/luci-go: git_revision:413d434bd4eee1130614494dfb19f1eba03d71af..git_revision:d1c03082ecda0148d8096f1fd8bf5491eafc7323
TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: Ibb094d77652d05496ae7edfe50667e6b5a7ad8e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3216203
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77352}
Those types have different definitions depending on the platform and the
standard library implementation, and require different format strings
for printing. Thus just use the default {float} and {double} types.
R=ecmziegler@chromium.org
Bug: chromium:1251165
Change-Id: I8253dd3d1d917a8f66e44a84e5fc8662036ffa0d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218162
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77350}
Change ThreadState representation from a fixed set of values to
either Parked or Running with two additional flags (or bits) that
are used when either a collection or a safepoint requested. Setting
either of these flags forces Park(), Unpark() and Safepoint() into
their slow path.
Currently we use the CollectionRequested flag on the main thread,
while SafepointRequested is used on background threads.
In case the slow path sees the CollectionRequested flag, it will
perform a GC. When encountering the SafepointRequested flag, the
background thread will participate in the safepoint protocol and
park itself for the duration of the safepoint operation.
This CL is a prerequisite for supporting safepoints across multiple
isolates. When safepointing multiple isolates, the main thread will
use both the CollectionRequested and SafepointRequested flag. This
isn't possible with the current system.
Design Doc: https://docs.google.com/document/d/1y6C9zAACEr0sBYMIYk3YpXosnkF3Ak4CEuWJu1-3zXs/edit?usp=sharing
Bug: v8:11708
Change-Id: I16b88740182d9c13bce54be163b334761529a5f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211894
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77349}
Adds support for double-word aligned, i.e., 8 bytes on 32-bit
platforms and 16 bytes on 64-bit platforms, objects in Oilpan.
Changes:
- Adds generic alignment APIs and overrides.
- Internal logic to support double-word aligned allocations on LABs.
- Adjusts natural alignment of large objects to follow double-word.
- Adds a new static_assert() that suggests users file a bug if higher
alignment is required.
- Statically checks that no allocations with non-default alignment
target custom spaces that support compaction.
Bug: v8:12295
Change-Id: I05766ce2349055d5d78b68919be00e7ee91d5505
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218150
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77348}
This reverts commit 9fe53c4f0b.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20isolates/17044/overview
Original change's description:
> [flags] Skip --random-seed in FlagList::Hash
>
> Node and friends use --random-seed to temporary reset the seed for
> predictable code-cache creation. To allow custom random seeds at runtime
> the flag is reset for encoding the FlagList::Hash in the snapshots.
>
> We will soon disallow changing flags via the API after V8 has been
> initialized. In order to make node work we will exclude --random-seed
> from the FlagList::Hash calculation.
>
> Drive-by-fix:
> * Lazily initialize flag_hash instead of calculating it after every call
> to SetFlagsFromString / EnforceFlagImplications.
> * Simplify hash string source creation since out << flag now includes
> the full flag information
>
> Bug: v8:12309
> Change-Id: I1a168f4702d8c4d160ff12fdbea881731e4ea8b6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218159
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77345}
Bug: v8:12309
Change-Id: I5e431c3e3ccccaab2ef7aa025b51d42f837f08b9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218979
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77347}
Node and friends use --random-seed to temporary reset the seed for
predictable code-cache creation. To allow custom random seeds at runtime
the flag is reset for encoding the FlagList::Hash in the snapshots.
We will soon disallow changing flags via the API after V8 has been
initialized. In order to make node work we will exclude --random-seed
from the FlagList::Hash calculation.
Drive-by-fix:
* Lazily initialize flag_hash instead of calculating it after every call
to SetFlagsFromString / EnforceFlagImplications.
* Simplify hash string source creation since out << flag now includes
the full flag information
Bug: v8:12309
Change-Id: I1a168f4702d8c4d160ff12fdbea881731e4ea8b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218159
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77345}
