With caged heap enabled, we can halve Member<> by storing only the least
significant half. The base of the heap is stored in a thread local
variable. The feature has therefore an implication that only single heap
is allowed per thread.
The feature is gated by the new GN arg:
cppgc_enable_pointer_compression.
Bug: chromium:1325007
Change-Id: Ic7f1ecb7b9ded57caad63d95bbc8e8ad6ad65031
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739979
Reviewed-by: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Almothana Athamneh <almuthanna@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80518}
Add new opcode numbers for relaxed-simd opcodes as in:
https://github.com/WebAssembly/relaxed-simd/pull/61, and updates
for decoded opcodes larger than two bytes.
Bug: v8:12284
Change-Id: I0bff22812243a39599bfeee3c0bc69171dd3c7d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625835
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80432}
Many uses of "volatile" are deprecated in C++20 because they don't
actually do anything. Remove "volatile" in these cases.
Bug: chromium:1284275
Change-Id: I64a3989d73f25e0cd933375dd6fa0b3f2b3acb54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3630343
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80428}
Allocation granularity (8 bytes on 64bit platforms) is already subsumed
by whatever range size we choose.
Bug: chromium:1029379
Change-Id: Iab95e6f36955c9ffbbe9ea0c98cb9d1f8dd0337b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3629869
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80415}
- Repurpose flag `treat_global_objects_as_roots` when taking a heap
snapshot for toggling whether internals should be exposed (to
`hide_internals`).
- Use the toggle in creating heap snapshots for exposing class names
as object names for C++ objects that have not explicitly been given a
name.
Change-Id: I77d71babfdfe53269964fe81ed985037a431c28b
Bug: chromium:1321620
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3623740
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80391}
This prevents ambiguity errors in C++20 due to ADL when casting types in
std::, which gains std::bit_cast<>().
Bug: chromium:1284275
Change-Id: I25046d1952a9304852e481ad8b84049c6769c289
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3625838
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80378}
Before this CL, the heap object name of unnamed objects(those not
inheriting from NameProvider) would be solely determined by whether the
build-time configuration cppgc_enable_object_names is enabled.
This patch adds a way to override that value at runtime. This is
useful for preserving default behavior with custom builds but at the
same time allow them to still enable the feature.
Bug: chromium:1321620
Change-Id: I3aa06db15e58d9ba9773be6797572f17f007e9ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620279
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80338}
To be consistent with the all the other tiers and avoid confusion, we
rename --opt to ---turbofan, and --always-opt to --always-turbofan.
Change-Id: Ie23dc8282b3fb4cf2fbf73b6c3d5264de5d09718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610431
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80336}
This fixes:
runtime error: upcast of misaligned address 0x000000000001
for type 'cppgc::internal::(anonymous namespace)::SimpleGCed<64>', which
requires 8 byte alignment
Bug: chromium:1029379
Change-Id: Id03ce022e72fc07a18c171d4cf5e42f50cb684f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3622918
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80332}
Due to the consistent overhead of snapshot checksum verification
we ideally want to avoid it all-together. However there are still enough
devices out there that suffer from corrupted snapshots that might
cause hard to debug heap corruptions.
This CL exposes the calculated (dummy value for now) and the expected
snapshot checksum as a crash key, so it can be easily consulted during
investigation.
Note: The calculated crash key contains 0x0 for now as a dummy value. We
will come up with a strategy later-on to limit the overhead of
calculating the checksum.
Bug: v8:12195
Change-Id: I6da6d74c035cb6f9b0edae212a36e6c41c048a5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605813
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80325}
This is a reland of commit 9145388055
Fixed: properly reference the ClearedValue in CSA (i.e. without
the cage_base upper 32 bits).
Original change's description:
> Reland "[osr] Use the new OSR cache"
>
> This is a reland of commit 91da38831d
>
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
>
> Original change's description:
> > [osr] Use the new OSR cache
> >
> > This CL switches over our OSR system to be based on the feedback
> > vector osr caches.
> >
> > - OSRing to Sparkplug is fully separated from OSR urgency. If
> > SP code exists, we simply jump to it, no need to maintain an
> > installation request.
> > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> > If a valid target code object exists, we enter it *without*
> > calling into runtime to fetch the code object.
> > - Finally, OSR urgency still remains as the heuristic for
> > requesting Turbofan OSR compile jobs. Note it no longer has a
> > double purpose of being a generic untargeted installation
> > request.
> >
> > With the new system in place, we can remove now-unnecessary
> > hacks:
> >
> > - Early OSR tierup is replaced by the standard OSR system. Any
> > present OSR code is automatically entered.
> > - The synchronous OSR compilation fallback is removed. With
> > precise installation (= per-JumpLoop-bytecode) we no longer
> > have the problem of 'getting unlucky' with JumpLoop/cache entry
> > mismatches. Execution has moved on while compiling? Simply spawn
> > a new concurrent compile job.
> > - Remove the synchronous (non-OSR) Turbofan compile request now
> > that we always enter available OSR code as early as possible.
> > - Tiering into Sparkplug no longer messes with OSR state.
> >
> > Bug: v8:12161
> > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> > Commit-Queue: Jakob Linke <jgruber@chromium.org>
> > Auto-Submit: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80147}
>
> Bug: v8:12161
> Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80167}
Bug: v8:12161,chromium:1320189
Change-Id: Ibd9a2ab61f51ebb32a3f5a66f7c602faead71c3e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3620273
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80306}
The CL prepares the sources and the tests for enabling
cppgc_enable_young_generation by default. The static initializer
in YoungGenerationEnabler (due to v8::base::Mutex) changed to be lazy.
The tests are now checking the runtime flag.
Bug: chromium:1029379
Change-Id: I1497a3dd2b8d62c1acd48496821f07324b7944d5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616726
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80304}
This reverts commit 9145388055.
Reason for revert: Breaking the Fuchsia Deterministic Builder
Original change's description:
> Reland "[osr] Use the new OSR cache"
>
> This is a reland of commit 91da38831d
>
> Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
> on arm64.
>
> Original change's description:
> > [osr] Use the new OSR cache
> >
> > This CL switches over our OSR system to be based on the feedback
> > vector osr caches.
> >
> > - OSRing to Sparkplug is fully separated from OSR urgency. If
> > SP code exists, we simply jump to it, no need to maintain an
> > installation request.
> > - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> > If a valid target code object exists, we enter it *without*
> > calling into runtime to fetch the code object.
> > - Finally, OSR urgency still remains as the heuristic for
> > requesting Turbofan OSR compile jobs. Note it no longer has a
> > double purpose of being a generic untargeted installation
> > request.
> >
> > With the new system in place, we can remove now-unnecessary
> > hacks:
> >
> > - Early OSR tierup is replaced by the standard OSR system. Any
> > present OSR code is automatically entered.
> > - The synchronous OSR compilation fallback is removed. With
> > precise installation (= per-JumpLoop-bytecode) we no longer
> > have the problem of 'getting unlucky' with JumpLoop/cache entry
> > mismatches. Execution has moved on while compiling? Simply spawn
> > a new concurrent compile job.
> > - Remove the synchronous (non-OSR) Turbofan compile request now
> > that we always enter available OSR code as early as possible.
> > - Tiering into Sparkplug no longer messes with OSR state.
> >
> > Bug: v8:12161
> > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> > Commit-Queue: Jakob Linke <jgruber@chromium.org>
> > Auto-Submit: Jakob Linke <jgruber@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#80147}
>
> Bug: v8:12161
> Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80167}
Bug: v8:12161
Change-Id: I73e2d98660e9edfbe07a152a14402380ea9227de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3615219
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80287}
The CL uses the different scheme to enable the generational barrier. The
separate global counter (is_enabled_) keeps track of the number of heaps
that enable generational GC. If at least one of the heaps enables the
generational GC, the counter will enable the write barrier. Technically,
the counter could be merged with WriteBarrier::is_enabled_, but having a
separate variable allows us to keep DCHECKs if generational barrier is
enabled.
Bug: chromium:1029379
Change-Id: Iafaa76f96acb18a73f8bde7231434e68c04cb683
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3616518
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80281}
The CL introduces a new option --cppgc-young-generation. This option
can't be enabled statically, because V8 options are parsed after heap
initialization. The CL changes minor GC so that it can be enabled
dynamically. The way it works is as follows:
- the user calls YoungGenerationEnabler::Enable();
- a heap checks in the next atomic pause whether the flag was enabled;
- if so, the heap enables young generation for itself.
To avoid barrier regressions without young-generation enabled, the CL changes the meaning of the global flag is-any-incremental-or-concurrent-marking to is-barrier-enabled.
The runtime option would enable us to test young generation on try-
and performance-bots.
Bug: chromium:1029379
Change-Id: I664cccdcd208225ffcbf9901f1284b56d088c5c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607993
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80274}
This is a reland of commit 9d31f8663a
There were issues with --future flag implications on M1.
Original change's description:
> [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
>
> ... for V8 code space. The feature is currently disabled.
>
> In order to use fast W^X permission switching we must allocate
> executable pages with readable writable executable permissions (RWX).
> However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
> permission changing of RWX memory pages. This means that the code page
> headers must be allocated with RWX permissions too because otherwise
> it wouldn't be possible to allocate a large code page over the freed
> regular code page and vice versa.
>
> When enabled, the new machinery works as follows:
>
> 1) when memory region is reserved for allocating executable pages, the
> whole region is committed with RWX permissions and then decommitted,
> 2) since reconfiguration of RWX page permissions is not allowed on
> MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
> to change them,
> 3) the request to set RWX permissions in the executable page region
> just recommits the pages without changing permissions (see (1), they
> were already allocated as RWX and then discarded),
> 4) in order to make executable pages inaccessible one must use
> OS::DiscardSystemPages() instead of OS::DecommitPages() or
> setting permissions to kNoAccess because the latter two are not
> allowed by the MacOS (see (2)).
> 5) since code space page headers are allocated as RWX pages it's also
> necessary to switch between W^X modes when updating the data in the
> page headers (i.e. when marking, updating stats, wiring pages in
> lists, etc.). The new CodePageHeaderModificationScope class is used
> in the respective places. On unrelated configurations it's a no-op.
>
> The fast permission switching can't be used for V8 configuration with
> enabled pointer compression and disabled external code space because
> a) the pointer compression cage has to be reserved with MAP_JIT flag
> which is too expensive,
> b) in case of shared pointer compression cage if the code range will
> be deleted while the cage is still alive then attempt to configure
> permissions of pages that were previously set to RWX will fail.
>
> This also CL extends the unmapper unit tests with permissions tracking
> for discarded pages.
>
> Bug: v8:12797
> Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80238}
Bug: v8:12797
Change-Id: I0fe86666f31bad37d7074e217555c95900d2afba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610433
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80259}
There are three ways to parse /proc/self/maps in platform-linux.cc,
remove one to use common code. In the process, add a unit test, and fix
some issues in the latest iteration of /proc/self/maps parsing.
Change-Id: I4701ea49fe8cce53aea0179e194dc48fbebb2ff5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605226
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80258}
For some reason the compiler was optimizing away the reference to the
object in WeakContainerTest.ConservativeGCTracesWeakContainer and thus
not finding it conservatively.
This CL revises the tests such that the compiler is no longer able to
optimize references away.
Bug: v8:12824
Change-Id: Ie598a1cf1124c2983a6c61fd4e990734d36f5832
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610627
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80257}
This reverts commit 9d31f8663a.
Reason for revert: crashes on Mac/arm64 bots:
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20debug/5923/overview
Original change's description:
> [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1)
>
> ... for V8 code space. The feature is currently disabled.
>
> In order to use fast W^X permission switching we must allocate
> executable pages with readable writable executable permissions (RWX).
> However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
> permission changing of RWX memory pages. This means that the code page
> headers must be allocated with RWX permissions too because otherwise
> it wouldn't be possible to allocate a large code page over the freed
> regular code page and vice versa.
>
> When enabled, the new machinery works as follows:
>
> 1) when memory region is reserved for allocating executable pages, the
> whole region is committed with RWX permissions and then decommitted,
> 2) since reconfiguration of RWX page permissions is not allowed on
> MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
> to change them,
> 3) the request to set RWX permissions in the executable page region
> just recommits the pages without changing permissions (see (1), they
> were already allocated as RWX and then discarded),
> 4) in order to make executable pages inaccessible one must use
> OS::DiscardSystemPages() instead of OS::DecommitPages() or
> setting permissions to kNoAccess because the latter two are not
> allowed by the MacOS (see (2)).
> 5) since code space page headers are allocated as RWX pages it's also
> necessary to switch between W^X modes when updating the data in the
> page headers (i.e. when marking, updating stats, wiring pages in
> lists, etc.). The new CodePageHeaderModificationScope class is used
> in the respective places. On unrelated configurations it's a no-op.
>
> The fast permission switching can't be used for V8 configuration with
> enabled pointer compression and disabled external code space because
> a) the pointer compression cage has to be reserved with MAP_JIT flag
> which is too expensive,
> b) in case of shared pointer compression cage if the code range will
> be deleted while the cage is still alive then attempt to configure
> permissions of pages that were previously set to RWX will fail.
>
> This also CL extends the unmapper unit tests with permissions tracking
> for discarded pages.
>
> Bug: v8:12797
> Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80238}
Bug: v8:12797
Change-Id: Ic07948e036db36326d464a2a901d052aa060a406
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3611665
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80239}
... for V8 code space. The feature is currently disabled.
In order to use fast W^X permission switching we must allocate
executable pages with readable writable executable permissions (RWX).
However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further
permission changing of RWX memory pages. This means that the code page
headers must be allocated with RWX permissions too because otherwise
it wouldn't be possible to allocate a large code page over the freed
regular code page and vice versa.
When enabled, the new machinery works as follows:
1) when memory region is reserved for allocating executable pages, the
whole region is committed with RWX permissions and then decommitted,
2) since reconfiguration of RWX page permissions is not allowed on
MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts
to change them,
3) the request to set RWX permissions in the executable page region
just recommits the pages without changing permissions (see (1), they
were already allocated as RWX and then discarded),
4) in order to make executable pages inaccessible one must use
OS::DiscardSystemPages() instead of OS::DecommitPages() or
setting permissions to kNoAccess because the latter two are not
allowed by the MacOS (see (2)).
5) since code space page headers are allocated as RWX pages it's also
necessary to switch between W^X modes when updating the data in the
page headers (i.e. when marking, updating stats, wiring pages in
lists, etc.). The new CodePageHeaderModificationScope class is used
in the respective places. On unrelated configurations it's a no-op.
The fast permission switching can't be used for V8 configuration with
enabled pointer compression and disabled external code space because
a) the pointer compression cage has to be reserved with MAP_JIT flag
which is too expensive,
b) in case of shared pointer compression cage if the code range will
be deleted while the cage is still alive then attempt to configure
permissions of pages that were previously set to RWX will fail.
This also CL extends the unmapper unit tests with permissions tracking
for discarded pages.
Bug: v8:12797
Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80238}
tests where moved from cctest to unittests under this cl:
https://crrev.com/c/3607370
Bug: v8:12781
Change-Id: If625e0dda51034e731c5e7fe87d591dce9804888
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3611182
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80227}
Add flag --always-use-string-forwarding-table to always use the
forwarding table (usually only used for shared strings) instead of
ThinString migrations initially (during GC strings will be migrated
to normal ThinStrings). The goal is to get more coverage of this code
that is designed for shared strings.
Bug: v8:12007
Change-Id: I7eb2e5ccf0018c4ac349611aebe337d8288de5c8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3536650
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80206}
Introduce a bottleneck for right-trimming an object. In a subsequent CL
we will use this method to update the cached size of invalidated
objects.
This CL also tries to clean-up the various CreateFillerObjectAt
methods. CreateFillerObjectAtRaw is now the internal method for all
these methods. After moving right-trimming to NotifyObjectSizeChange,
both CreateFillerObjectAt and CreateFillerObjectAtBackground don't need
those arguments for clearing slots or memory anymore.
Bug: v8:12578, chromium:1316289
Change-Id: I6ff0bfaced3e0a1765152700e68a4ad33a155723
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3607992
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80200}
It's necessary to support fast W^X permission switching on MacOS on
ARM64 ("Apple M1"/Apple Silicon) where permission modification of RWX
pages to anything else is prohibited.
On all the other architectures/platforms RecommitPages() is equivalent
to SetPermissions().
The new API will be used in a follow-up CLs.
Bug: v8:12797
Change-Id: Id0d8b8c42c81b80cd8fa6b47c227680d7d1f9b10
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606231
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Samuel Groß <saelo@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80190}
When setting a range for a newly allocated lab, consider adjacent cards.
If either is young, don't mark it as kMixed.
Bug: chromium:1029379
Change-Id: If7d1d920dd5769679de68800eae61f3a8dc1eb17
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3584116
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80175}
This is a reland of commit 91da38831d
Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization
on arm64.
Original change's description:
> [osr] Use the new OSR cache
>
> This CL switches over our OSR system to be based on the feedback
> vector osr caches.
>
> - OSRing to Sparkplug is fully separated from OSR urgency. If
> SP code exists, we simply jump to it, no need to maintain an
> installation request.
> - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> If a valid target code object exists, we enter it *without*
> calling into runtime to fetch the code object.
> - Finally, OSR urgency still remains as the heuristic for
> requesting Turbofan OSR compile jobs. Note it no longer has a
> double purpose of being a generic untargeted installation
> request.
>
> With the new system in place, we can remove now-unnecessary
> hacks:
>
> - Early OSR tierup is replaced by the standard OSR system. Any
> present OSR code is automatically entered.
> - The synchronous OSR compilation fallback is removed. With
> precise installation (= per-JumpLoop-bytecode) we no longer
> have the problem of 'getting unlucky' with JumpLoop/cache entry
> mismatches. Execution has moved on while compiling? Simply spawn
> a new concurrent compile job.
> - Remove the synchronous (non-OSR) Turbofan compile request now
> that we always enter available OSR code as early as possible.
> - Tiering into Sparkplug no longer messes with OSR state.
>
> Bug: v8:12161
> Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80147}
Bug: v8:12161
Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80167}
This reverts commit 91da38831d.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview
Original change's description:
> [osr] Use the new OSR cache
>
> This CL switches over our OSR system to be based on the feedback
> vector osr caches.
>
> - OSRing to Sparkplug is fully separated from OSR urgency. If
> SP code exists, we simply jump to it, no need to maintain an
> installation request.
> - Each JumpLoop checks its dedicated FeedbackVector cache slot.
> If a valid target code object exists, we enter it *without*
> calling into runtime to fetch the code object.
> - Finally, OSR urgency still remains as the heuristic for
> requesting Turbofan OSR compile jobs. Note it no longer has a
> double purpose of being a generic untargeted installation
> request.
>
> With the new system in place, we can remove now-unnecessary
> hacks:
>
> - Early OSR tierup is replaced by the standard OSR system. Any
> present OSR code is automatically entered.
> - The synchronous OSR compilation fallback is removed. With
> precise installation (= per-JumpLoop-bytecode) we no longer
> have the problem of 'getting unlucky' with JumpLoop/cache entry
> mismatches. Execution has moved on while compiling? Simply spawn
> a new concurrent compile job.
> - Remove the synchronous (non-OSR) Turbofan compile request now
> that we always enter available OSR code as early as possible.
> - Tiering into Sparkplug no longer messes with OSR state.
>
> Bug: v8:12161
> Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Auto-Submit: Jakob Linke <jgruber@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80147}
Bug: v8:12161
Change-Id: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608
Auto-Submit: Nico Hartmann <nicohartmann@chromium.org>
Owners-Override: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#80148}
This CL switches over our OSR system to be based on the feedback
vector osr caches.
- OSRing to Sparkplug is fully separated from OSR urgency. If
SP code exists, we simply jump to it, no need to maintain an
installation request.
- Each JumpLoop checks its dedicated FeedbackVector cache slot.
If a valid target code object exists, we enter it *without*
calling into runtime to fetch the code object.
- Finally, OSR urgency still remains as the heuristic for
requesting Turbofan OSR compile jobs. Note it no longer has a
double purpose of being a generic untargeted installation
request.
With the new system in place, we can remove now-unnecessary
hacks:
- Early OSR tierup is replaced by the standard OSR system. Any
present OSR code is automatically entered.
- The synchronous OSR compilation fallback is removed. With
precise installation (= per-JumpLoop-bytecode) we no longer
have the problem of 'getting unlucky' with JumpLoop/cache entry
mismatches. Execution has moved on while compiling? Simply spawn
a new concurrent compile job.
- Remove the synchronous (non-OSR) Turbofan compile request now
that we always enter available OSR code as early as possible.
- Tiering into Sparkplug no longer messes with OSR state.
Bug: v8:12161
Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80147}
There is currently a bug in docker where fstat may not
return the correct device id and as a result a check under
`OS::RemapPages, stat_buf.st_dev != enclosing_region.dev`
fails, details on the bug:
https://github.com/moby/moby/issues/43512
Platform specific page sizes are also defined for kMaxPageSize
to fix compilation errors.
Change-Id: I026609329aa6432eda4f1880a0f586c0c2162461
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3601211
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Junliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#80111}
Removes support for specifying weak handles with finalizers that allow
for object resurrection.
This CL removes the public facing APIs. Internal support will be
removed in a follow up.
Bug: v8:12672
Change-Id: Ia6ea269093aaa128caadb7508aca2e5a1254923c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596174
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80070}
Reason for reland: Fixed Fuchsia build.
Original change's description:
> [builtins] Remap builtins on Linux
>
> This is a CL similar to
> https://chromium-review.googlesource.com/c/v8/v8/+/3553006, but on Linux
> rather than macOS. The goal is to allow builtins to use short builtin
> calls without paying a memory cost, by remapping rather than copying
> them.
>
> However, while macOS has a system call making this easier, on Linux we
> don't have one on most kernels. There is the recently-introduced
> mremap(MREMAP_DONTUNMMAP), which is available in 5.7, but only works on
> anonymous mappings until 5.13, which is too recent for most Android
> devices.
>
> Instead, we open() the file containing the builtins, and mmap() it at
> the desired location.
>
> Change-Id: I4524f349948b8f48c4536cf392a1cd179662a6cc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570426
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Commit-Queue: Benoit Lize <lizeb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80022}
Change-Id: I0cc8cf510bd2cb8621130bea8406d79aa209948c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596164
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80049}
.. which points back at the corresponding feedback vector slot for each
JumpLoop bytecode.
Bug: v8:12161
Change-Id: I95f4d013544a69e088314655af7eb1dc504a8657
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596166
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80048}
This reverts commit b1dd828707.
Reason for revert: Breaking fuschia build https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Fuchsia%20-%20builder/13592/overview
Original change's description:
> [builtins] Remap builtins on Linux
>
> This is a CL similar to
> https://chromium-review.googlesource.com/c/v8/v8/+/3553006, but on Linux
> rather than macOS. The goal is to allow builtins to use short builtin
> calls without paying a memory cost, by remapping rather than copying
> them.
>
> However, while macOS has a system call making this easier, on Linux we
> don't have one on most kernels. There is the recently-introduced
> mremap(MREMAP_DONTUNMMAP), which is available in 5.7, but only works on
> anonymous mappings until 5.13, which is too recent for most Android
> devices.
>
> Instead, we open() the file containing the builtins, and mmap() it at
> the desired location.
>
> Change-Id: I4524f349948b8f48c4536cf392a1cd179662a6cc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570426
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Jakob Linke <jgruber@chromium.org>
> Commit-Queue: Benoit Lize <lizeb@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#80022}
Change-Id: I0093fe84216f8c8fd1a8691c53817e578d92fa40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3594009
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Owners-Override: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80028}
- Add RunJSNoChecked to run the script which possibly throws.
- Add CompileRun to run the script outside TEST_F, e.g., in
FunctionTemplate and helpers etc.
Bug: v8:12781
Change-Id: Ibab2e19cf1f7c76f7a81a90fc5894e7e6bfb7cdf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3586770
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: 王澳 <wangao.james@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#80025}
This is a CL similar to
https://chromium-review.googlesource.com/c/v8/v8/+/3553006, but on Linux
rather than macOS. The goal is to allow builtins to use short builtin
calls without paying a memory cost, by remapping rather than copying
them.
However, while macOS has a system call making this easier, on Linux we
don't have one on most kernels. There is the recently-introduced
mremap(MREMAP_DONTUNMMAP), which is available in 5.7, but only works on
anonymous mappings until 5.13, which is too recent for most Android
devices.
Instead, we open() the file containing the builtins, and mmap() it at
the desired location.
Change-Id: I4524f349948b8f48c4536cf392a1cd179662a6cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570426
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80022}
Immediate version of the Bitclear instruction can be used for logical
And with some immediates. It can also be used to implement
And(x, Not(imm)) in a single instruction. This patch gives ~0.5% runtime
improvement in one benchmark on Neoverse N1.
Change-Id: Ia926c6746f0c252f81626c6fca21c4dfb41679d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160667
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/main@{#80015}
This is a reland of commit 4d8e1846a7
One of the Mac arm64 bots failed to link an exported thread_local
static variable (crbug/1316800).
Original change's description:
> [rwx][mac] Introduce RwxMemoryWriteScope
>
> ... as a single bottleneck that encapsulates the semantics and
> implementation of fast per-thread W^X permission switching supported
> by Apple Silicon (arm64 M1).
> On other architectures this class is a no-op.
>
> Bug: v8:12797
> Change-Id: Ica842ff9f843e20b7f61fd7e80591e7a1fd29771
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3586986
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79994}
Bug: v8:12797
Change-Id: Ifbd15c233bb343f11daa89b1328b5bf65c4806f4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3591332
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80011}
This reverts commit 4d8e1846a7.
Reason for revert: Blocks V8 roll, crbug.com/1316800
Original change's description:
> [rwx][mac] Introduce RwxMemoryWriteScope
>
> ... as a single bottleneck that encapsulates the semantics and
> implementation of fast per-thread W^X permission switching supported
> by Apple Silicon (arm64 M1).
> On other architectures this class is a no-op.
>
> Bug: v8:12797
> Change-Id: Ica842ff9f843e20b7f61fd7e80591e7a1fd29771
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3586986
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79994}
Bug: v8:12797
Change-Id: I81792567839e72b4147d009c0845b0c0de003eb0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3590752
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@{#80007}
... as a single bottleneck that encapsulates the semantics and
implementation of fast per-thread W^X permission switching supported
by Apple Silicon (arm64 M1).
On other architectures this class is a no-op.
Bug: v8:12797
Change-Id: Ica842ff9f843e20b7f61fd7e80591e7a1fd29771
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3586986
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79994}
This reduces card granularity from 4096 to 512 bytes with the goal to
improve write barrier filtering.
Bug: chromium:1029379
Change-Id: I22e2a9c61ef4c36c3db65404370213d0a8048e08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3582393
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79960}
For a while, we shipped a version which writes version 13 data with
JSArrayBufferView flags, and then fixed version 13 to not include the
flags.
This CL adds a compatibility mode for parsing the the version 13
data which includes the flags, since it still occurs in the wild.
Bug: chromium:1314833,chromium:1284506
Change-Id: I96cc432c8574a40b11ec0037394feb1853515760
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3583982
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79959}
Tracer scopes are used in numerous places in src/heap to track time
spent during various phases of the garbage collection. Usually, they
are introduced with the TRACE_GC* family of macros, taking the scope
identifier as a parameter. At most call sites, the scope identifier is
known at compile time.
This CL inlines the constructor and destructor of GCTracer::Scope, in
order to enable the C++ compiler to properly optimize the introduction
of such scopes when the scope identifier is known at compile time,
using constant propagation. This is expected to have a performance
impact for short-lived and frequently used scopes, e.g., in incremental
marking and sweeping steps.
Change-Id: I6f1a2954a437de1fa6dab5e464c20c952d84ffd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581774
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79957}
Method GCTracer::UpdateStatistics was responsible for copying
incremental and background scopes to the current event, before
reporting. It was called, however, at the end of the atomic pause and,
as a result, some of these scopes would be prematurely copied to the
current event (e.g., incremental and background sweeping scopes) and
misreported.
This CL fixes this by splitting the update of statistics and the
copying of incremental and background scopes. It introduces the
method GCTracer::FinalizeCurrentEvent which does the latter, which
is called from GCTracer::StopCycle. It also introduces methods for
correctly accessing and updating scopes, before the current event is
finalized, and eliminates the distinction between
GCTracer::AddScopeSample and GCTracer::AddScopeSampleBackground.
Bug: chromium:1154636
Change-Id: I2a6d9abb3daa2c48b2dce12dc2685cfc84130abf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576792
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79938}
To make the existing mechanism for printing JSON for turbolizer able to
print types other than the ones stored in the nodes (so the verifier can
print its own types here), this CL restructures the printing mechanism
into a single non-private class that can be inherited to override
certain parts of the printing. In this CL only GetType is made virtual
to allow verifier to override it, but additional parts can be made
overridable whenever necessary.
Bug: v8:12619
Change-Id: Idf31f8cdb49eb6c3204c6abfbb74fc981330d6d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571818
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79909}
Similar to full GCs, the GC defers metric reporting until sweeping is
finished.
Bug: chromium:1029379
Change-Id: Ib06adb3be691c1ad2bd530eb77fc01cc22537338
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576130
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79891}
They can be replaced by std::conjunction and c++17 folding expressions.
R=tebbi@chromium.org
Bug: v8:12425
Change-Id: I109ac904245aab431f11752eff5129fd4361de8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570428
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79843}
Also add a mixin for using the single-threaded default platform instead
of swapping it in with SetPlatformForTesting.
Bug: v8:12781
Change-Id: I304303e58ed713e5558d108cd7eb826c17abb40f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3574553
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79829}
This CL only refactors code in the sweeper without changing behavior.
This method can be simplified by moving duplicate code into new methods.
Also move definition of FreeRangesMap into TypedSlotSet and replace all
usages of that raw map type with that type-alias.
Since we are already here, remove the unused argument in
Sweeper::FreeAndProcessFreedMemory.
Bug: v8:12760
Change-Id: Ifa1848b456aef7955eccbaafc00df55fbcbc385c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3574542
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79822}
Change the unittest runner to no longer uncondtionally set up a default
platform in the "environment", but to instead make platform set-up part
of the "mixin" framework for test fixtures.
Requires modifying some tests that expect the platform to be available,
and all flag implications resolved, before the mixin constructors run.
We still keep the environment for setting up the process for cppgc. This
process setup can only be done once per process, so it can no longer use
the platform -- that's ok though, the page allocator used by cppgc's
process initialisation doesn't have to be the same as the platform's so
we can just pass in a separate new one.
Change-Id: Ic8ccf39722e8212962c5bba87350c4b304388a7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571886
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79820}
This reverts commit 8d51d561d5.
Reason for revert: This has runtime failures because including
cmx fragments isn't working ocrrectly. Still investigating why
this wasn't discovered by CQ.
Original change's description:
> [fuchsia] Use SDK provided gn templates for v8_unittests
>
> cr_fuchsia_package is deprecated in favor of using the Fuchsia
> SDK provided rules directly.
>
> Bug: chromium:1092804
> Change-Id: I86a59b6a717cb0aa8c3473e8410bdd98f0ffd042
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3537883
> Reviewed-by: Victor Gomes <victorgomes@chromium.org>
> Reviewed-by: Wez <wez@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Commit-Queue: Bryant Chandler <bryantchandler@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79763}
Bug: chromium:1092804
Change-Id: I33e8a6f07c99d7040cffa579a95508e79904889e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3572005
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79796}
The CL makes sure to extract and copy Oilpan young GC metrics to
v8::metrics::GarbageCollectionYoungCycle. In addition, it makes sure
that metrics are not reported twice by bailing out from
GCTracer::NotifyCppGCCompleted() for young GC cycles (the metrics are
reported later in Heap::CollectGarbage() by calling
GCTracer::StopCycle()).
Bug: chromium:1029379
Change-Id: I07bf51e85a76a7cdbeeb8d87c9072edf2634158b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545168
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79766}
Tweak a few names, remove a few GetIsolate calls, other minor
usability refactors.
It may be worth taking a closer look at the impl in the future,
currently the design choices don't seem ideal (see the added TODO
on top of the class).
The reland is unchanged from the original CL.
Bug: v8:12161
Change-Id: I9971f7f2fb08b7a1ec2d57b2a0e4accdc11191ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568444
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79759}
- Unhandlify OSROptimizedCodeCache::GetOptimizedCode.
- Unstatic-fy FeedbackVector::SetOptimizedCode.
- Remove frame-walking logic during the OSR tierup decision.
The reland is unchanged from the original CL.
Bug: v8:12161
Change-Id: Ibf03a9dd9a6fcd38c0664e5d5014a26d0240e035
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568463
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79752}
For short builtin calls, the builtins are copied on the heap when they
cannot be put close enough to be in range of relative calls. This costs
memory, as the embedded builtins are part of the binary, and mapped from
the binary, and as a consequence shared with all running processes.
Rather than copying the memory, we can remap it at a different address,
avoiding the memory cost. This CL does that, on ARM64 macOS only for
now.
This saves at least ~1.4MiB of memory per V8 process. See below the
output of vmmap <PID>:
[...]
Memory Tag 255 7408308000-740833c000 [ 208K 144K 144K 0K] r-x/rwx SM=ZER
Memory Tag 255 740833c000-7408340000 [ 16K 0K 0K 0K] ---/rwx SM=ZER
Memory Tag 255 7408344000-7408348000 [ 16K 0K 0K 0K] ---/rwx SM=ZER
Memory Tag 255 7408348000-740837c000 [ 208K 144K 144K 0K] r-x/rwx SM=ZER
Memory Tag 255 740837c000-740fe80000 [123.0M 0K 0K 0K] ---/rwx SM=ZER
mapped file 740fe80000-740ffe4000 [ 1424K 1328K 0K 0K] r-x/rwx SM=COW ...pp/Contents/Frameworks/Chromium Framework.framework/Versions/102.0.4958.0/Chromium Framework
Memory Tag 255 740ffe4000-7410000000 [ 112K 0K 0K 0K] ---/rwx SM=ZER
The "208K" regions are 256kiB code pages, minus the header and guard
pages, meaning that they are code chunks. The mapped file are the
remapped builtins, showing that they aren't copied, but remapped from
the binary.
Bug: chromium:1298417
Change-Id: Ia30a43e671726d01450a7db0ecb7777b34763053
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3553006
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79716}
