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}
This reverts commit d87e5f42f3.
Reason for revert: Causes issues by eliminating stores that can be observed by GC. Flagging stores as "initializing" needs better handling than what was done in this CL.
Original change's description:
> [turbofan] Handle Allocations in StoreStoreElimination
>
> Previously, StoreStoreElimination handled allocations as
> "can observe anything". This is pretty conservative and prohibits
> elimination of repeated double stores to the same field.
> With this CL allocations are changed to "observes initializing stores".
> This way it is guaranteed that initializing stores to a freshly created
> object are not eliminated before allocations (that can trigger GC), but
> allows elimination of non-initializing, unobservable stores in the
> presence of allocations.
>
> Bug: v8:12200
> Change-Id: I5ef1ca8892a84a3b332e081e2fa6285d0eba9d46
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211585
> Commit-Queue: Patrick Thier <pthier@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77299}
Bug: v8:12200
Change-Id: I0f18cbc3e848011f1a998b073b05b3bdbc4e1223
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218158
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Patrick Thier <pthier@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77342}
Connecting moves can be inserted in the gap of the last instruction of a
block by the register allocator. The implicit assumption is that the
last instruction does not have any operand, so that the connecting move
does not invalidate any use of the destination operand.
Deoptimization breaks this assumption as it both terminates its block
and has operands. Omit the connecting move in this case to avoid
invalidating the deopt operands.
R=nicohartmann@chromium.org
Bug: v8:12218
Change-Id: Icce8e455949b19338ec7255dbb9b37963e857a6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211572
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77341}
Used to be needed for streaming but we don't use it anymore.
Change-Id: I0947155bec38a6b329452e42204f07170a72c155
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217195
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77339}
Port commit 6bd44dfe57
Port commit 89933af67f
Port commit 255aaed95b
Port commit 7511020bc8
Port commit aa259e30c3
Bug: v8:11112
Change-Id: Ia005a5da2d48505926a19a5d238b606826db1135
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3215372
Auto-Submit: Liu yu <liuyu@loongson.cn>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77338}
.. instead of referring to them through magic chars {s,S,w,W,d,D,n,.,*}.
Change-Id: Ib50937a2a7d4229a021377586a54be3db9ed8c1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217196
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77337}
GetUnusedRegister may spill registers and thus modify stack slots.
Therefore, we have to call it before fetching stack slots.
Bug: v8:7748
Change-Id: If7873efd986d9a7a6869fa8ec156d45affd7a8aa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3217199
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77334}
The previous implementation would not explicitly send
`Debugger.paused` events for instrumentation breakpoints
if they were to overlap with breaks due to:
* regular breakpoints
* OOM
* exceptions
* asserts
This CL is a step towards making sure that a separate
`Debugger.paused` event is always sent for an instrumentation
breakpoint. In some cases where we have overlapping reasons
but only know of one, the 'instrumentation' reason,
we still just send out one paused event with the reason
being `instrumentation`.
Drive-by: send instrumentation notification to all sessions,
remember which breakpoints are instrumentation breakpoints
Bug: chromium:1229541, chromium:1133307
Change-Id: Ie15438f78b8b81a89c64fa291ce7ecc36ebb2182
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211892
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77333}
Land some of the tests for Temporal.PlainDateTime
All marked as FAIL at this stage.
Bug: v8:11544
Change-Id: I09bf681e61f19d96607c848ddcb6bee06580aff1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085625
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77332}
