The most critical barrier (CombinedWriteBarrierSlow) was already
annotated. Add more annotations to cover all the collection use cases
as well.
Speedometer3
👍 TodoMVC-Preact-Complex-DOM [ -1.1%, -0.0%]
Bug: 537244297
Change-Id: Ie9f1823ba99f5e2ca8b15d446c10acf88b302d49
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8126059
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#108791}
Place GCInfo objects into a separate section (`gc_info_section` or
`__DATA,gc_info_section`) and compute the index directly as an offset
from the start of the section. This avoids the overhead of dynamic
registration and checking on allocation. This also eliminates the need
for `GCInfoTable` when active.
The optimization is enabled by default on desktop (Linux and macOS)
under the `cppgc_enable_object_section_gcinfo` GN flag for non-component
builds.
ELF and MachO platforms are supported.
TAG=agy
Change-Id: I83b5bf36dd8f0d0f469caf3dc8db4eb9464c2250
Bug: 522693606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7918333
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107939}
Enabling cppgc_enable_object_names causes ASAN false positives
when iterating cross-thread persistents. This is because of the
access to the location_ field. This CL fixes this by silencing
ASAN for this access similar to what we do for GetNodeFromGC() or
ClearFromGC().
Bug: 497855658
Change-Id: I6af31de5b6273a8cfde835388dbf64e826a65ef9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7865927
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107520}
This CL initially enables this "gn arg" on Desktop platforms. Android
and Fuchsia can be enabled later as well.
Bug: 497855658
Change-Id: I09696c4df93f403a7eff349a74037e1ee167a557
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7807042
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107492}
This reverts commit b284c48c16.
Reason for revert: Performance regressions in event dispatch, presumably from LLVM [[assume]] weaknesses; since we don't see any clear wins anywhere else (besides a bit in size), it's easier to just revert.
Original change's description:
> Make Uncompress(Compress(ptr)) into a no-op.
>
> Add an [[assume]] annotation so that Clang understands this; it doesn't
> by itself (because it requires information about high bits in the
> uncompressed pointer that we've found it hard to teach it).
>
> Doesn't give a Speedometer win by itself, but it reduces the APK size
> of 64-bit Chrome by ~11 kB.
>
> Change-Id: I1480f0032e3733972553b1e34eb4a7def5f157ed
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7277326
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Steinar H Gunderson <sesse@chromium.org>
> Auto-Submit: Steinar H Gunderson <sesse@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#104529}
Fixed: 474389112
Change-Id: I924a6613291a7f422736b3b914e7cc8dd58b2676
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7487369
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Steinar H Gunderson <sesse@chromium.org>
Cr-Commit-Position: refs/heads/main@{#104742}
Add an [[assume]] annotation so that Clang understands this; it doesn't
by itself (because it requires information about high bits in the
uncompressed pointer that we've found it hard to teach it).
Doesn't give a Speedometer win by itself, but it reduces the APK size
of 64-bit Chrome by ~11 kB.
Change-Id: I1480f0032e3733972553b1e34eb4a7def5f157ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7277326
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Steinar H Gunderson <sesse@chromium.org>
Auto-Submit: Steinar H Gunderson <sesse@chromium.org>
Cr-Commit-Position: refs/heads/main@{#104529}
The GCInfoIndex is always written on allocation. This does not affect
writing/reading the construction bit which happens with a mask.
This safes one shift in the allocation fast path (for GCInfoIndex).
Drive-by: Use std::atomic_ref instead of casts to std::atomic.
Change-Id: I8932f46ef582558d30eded9bab9b8d210a0ee1cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7213182
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#104077}
SourceLocation is almost only used for debug messages in TurboShaft, so
pass it only in debug mode. Additionally, std::source_location (that it
wraps) is a single pointer, so we can efficiently pass it by value
rather than const ref.
This reduces release build d8 by ~170kb, of which ~4kb is the by-value
passing.
Change-Id: Ia6b592f094dad0987b8a886bf16a7d3fe8611eb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6888815
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#102072}
This fixes the handling of intermediate values when conservatively
iterating memory (stack, but also heap).
To this end we will scan through memory word-by-word and consider:
1. Full pointers;
2. Compressed pointers in both half words;
3. A half-decompressed 35-bit value as intermediate state that doesn't
assume sign extension happened;
We also bring back the optimization from https://crrev.com/c/6198226
which relied on the fact that the full pointer will be reached through
the intermediate state. This is now actually the case and handling 3.
implicitly also handles 1.
The CL also adds a bunch of tests that would have caught the original
problem.
Change-Id: Ibde3af33894b1f044cde49e97492b46c3e4b4e24
Bug: 391018461
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6198347
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#98372}
The 2GB cage was already disabled for some time due to OOM errors. We
have also increased the cage from 4GB to 16GB already on non-Android
systems. So it seems unlikely that we could launch it again.
Bug: 343959927
Change-Id: I27c26256c84f4e592bb991d7b8a0582b54685e18
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6089581
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#97791}
This is a reland of commit 48bdf7ae9f
Original change's description:
> cppgc: Remove guard pages and avoid discarding pages on Windows
>
> This is a reland of https://crrev.com/c/6049213 with improved handling
> for Windows.
>
> This CL changes the guard page size to 0 on all platforms. Individual
> Oilpan pages thus have no more guard regions. The infrastructure will
> be removed in a subsequent CL.
>
> On Windows discarding memory on 128K-aligned 128K in size chunks
> caused massive performance regressions on syscalls.
>
> The CL works around this by removing discarding in the following ways:
> 1. On destroying pages the memory is not discarded anymore. This is
> okay because we only discard pages on memory reducing GCs which is
> also when we drop pages from the pool which decommits the memory
> anyways.
> 2. Discarding free list entries is disabled on Windows. This is in
> line with the JS heap part which has a similar exemption.
>
> Change-Id: I8623467ef06eb3be63cd62718db09dde65e4a763
> Bug: 378017037
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6055482
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#97600}
Cq-Include-Trybots: luci.v8.try:v8_win64_nodcheck_rel
Bug: 378017037
Change-Id: If02d76b37e39eb14949bc7a7769ce2771eaf1eab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6074477
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#97629}
This reverts commit 48bdf7ae9f.
Reason for revert: Fails on https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64/61462/overview
Original change's description:
> cppgc: Remove guard pages and avoid discarding pages on Windows
>
> This is a reland of https://crrev.com/c/6049213 with improved handling
> for Windows.
>
> This CL changes the guard page size to 0 on all platforms. Individual
> Oilpan pages thus have no more guard regions. The infrastructure will
> be removed in a subsequent CL.
>
> On Windows discarding memory on 128K-aligned 128K in size chunks
> caused massive performance regressions on syscalls.
>
> The CL works around this by removing discarding in the following ways:
> 1. On destroying pages the memory is not discarded anymore. This is
> okay because we only discard pages on memory reducing GCs which is
> also when we drop pages from the pool which decommits the memory
> anyways.
> 2. Discarding free list entries is disabled on Windows. This is in
> line with the JS heap part which has a similar exemption.
>
> Change-Id: I8623467ef06eb3be63cd62718db09dde65e4a763
> Bug: 378017037
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6055482
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#97600}
Bug: 378017037
Change-Id: I50949ea0085c60908984cf9489f9eac6fd466db0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6074950
Commit-Queue: Eva Herencsárová <evih@chromium.org>
Owners-Override: Eva Herencsárová <evih@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#97602}
This is a reland of https://crrev.com/c/6049213 with improved handling
for Windows.
This CL changes the guard page size to 0 on all platforms. Individual
Oilpan pages thus have no more guard regions. The infrastructure will
be removed in a subsequent CL.
On Windows discarding memory on 128K-aligned 128K in size chunks
caused massive performance regressions on syscalls.
The CL works around this by removing discarding in the following ways:
1. On destroying pages the memory is not discarded anymore. This is
okay because we only discard pages on memory reducing GCs which is
also when we drop pages from the pool which decommits the memory
anyways.
2. Discarding free list entries is disabled on Windows. This is in
line with the JS heap part which has a similar exemption.
Change-Id: I8623467ef06eb3be63cd62718db09dde65e4a763
Bug: 378017037
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6055482
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#97600}
This reverts commit e56d2eafd0.
Reason for revert: Heavily regresses Windows discarding time.
Original change's description:
> cppgc: Remove guard pages
>
> Guard pages (4K, 16K) were added on certain platforms within the 128K
> logical cppgc page. These regions have been implemented and dragged
> along from the initial version of Oilpan.
>
> For tooling these pages have no real use as we rely on ASAN for
> poisoning unused areas. OOB access for large objects is generally
> trapped on access in bounds checks. Other OOB access has to hit
> exactly the guard pages to trap which is not generally the case.
>
> The mechanism had no relevance for actual security as the sizes were
> small and their positiion was deterministic.
>
> This CL removes the guard page support. This gets us back some virtual
> address space in the cage and slightly makes getting to page handles
> cheaper (over the public API).
>
> Bug: 378017037
> Change-Id: I8bb2c17e2daa4ee76c8a29aeaeb46827948160c3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6049213
> Reviewed-by: Samuel Groß <saelo@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#97389}
Bug: 378017037, 381201234, 381120830, 380922994
Change-Id: Ia2b55934891fb176acb3473d15151e184c75d44d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6055557
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#97458}
Guard pages (4K, 16K) were added on certain platforms within the 128K
logical cppgc page. These regions have been implemented and dragged
along from the initial version of Oilpan.
For tooling these pages have no real use as we rely on ASAN for
poisoning unused areas. OOB access for large objects is generally
trapped on access in bounds checks. Other OOB access has to hit
exactly the guard pages to trap which is not generally the case.
The mechanism had no relevance for actual security as the sizes were
small and their positiion was deterministic.
This CL removes the guard page support. This gets us back some virtual
address space in the cage and slightly makes getting to page handles
cheaper (over the public API).
Bug: 378017037
Change-Id: I8bb2c17e2daa4ee76c8a29aeaeb46827948160c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6049213
Reviewed-by: Samuel Groß <saelo@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#97389}
These checks are currently not run in Blink at all because the debug
macros are different. Move them behind v8_enable_slow_dchecks to allow
some testing and try to later enable them more broadly.
This also fixes the issue that for DEBUG builds the sizeof(Member) is
out of sync between V8 and Blink.
Change-Id: I332fb82ffe8f7bb2b1a9a8fee3630be0b06ce471
Bug: 373485798
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5952933
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#96769}
cppgc's API-level checks have been gated behind `DEBUG` whereas Blink
always passes `_DEBUG` as symbol for debugging/dcheck builds.
Put the checks now behind a separate define that follows the common
practice of pairing a gn flag with a define for external usage.
This CL only enabled `CPPGC_DCHECK()` and leaves more expensive
verificaton for a follow up.
Bug: 373485798
Change-Id: Ic45738bb34569f3046118142350ecf7b6ac4439d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5934873
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#96665}
Currently policies just use `Get()` which will trigger a
decompression, even if the result is then not used in some
configurations.
This is a possible small perf win on some configurations
where the decompression was not optimized away.
Bug: 373485798
Change-Id: I72a4c79652c64f5461790dd5d5d8e54874c7e5bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5938964
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#96663}
Documentation states that CppHeap can be used with V8::Locker. However,
in several cases, the implementation enforced checks that disallowed
the switching of threads. In particular:
1. Finalizers and pre-finalizers were expected to run on the same thread
where the object was created.
2. Persistents were expected to be allocated and used by the thread that
created the heap (this was enforced either explicitly or by some
pointer policies).
This CL fixes this issue by loosening the checks, if the v8::Locker has
been used.
Bug: 373263965
Change-Id: I82b5ae5f2adc421ab33d283cf2c640edfa0915b9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5934624
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@{#96646}
This reverts commit 9144af8540.
Reason for revert: https://issues.chromium.org/issues/364340219
Original change's description:
> [cppgc] Make clearing of weak persistents concurrent
>
> Oilpan's weakness clearing phase often takes around 10% of the overall
> mark-compact pause. A small portion is taken by the clearing of
> same-thread WeakPersistent handles. This CL introduces a concurrent job
> for clearing such handles, in parallel to weak container callbacks.
>
> Bug: 349952799
> Change-Id: I497b199edd674379d552281125cdca65bc766bd3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5822092
> Reviewed-by: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#95872}
Bug: 349952799
Bug: 364340219
Change-Id: I81a5db34fa30cfddcb586b2265abe7239bd52140
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5877010
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#96207}
Oilpan's weakness clearing phase often takes around 10% of the overall
mark-compact pause. A small portion is taken by the clearing of
same-thread WeakPersistent handles. This CL introduces a concurrent job
for clearing such handles, in parallel to weak container callbacks.
Bug: 349952799
Change-Id: I497b199edd674379d552281125cdca65bc766bd3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5822092
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#95872}
clang-cl matches cl.exe in making [[no_unique_address]] a no-op and
requiring [[msvc::no_unique_address]] instead. Handle accordingly in V8
so that on Windows the macro actually has an effect.
Bug: none
Change-Id: I1eca1a00504ccd7f3b321afbcd9f7eaab8b4a797
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5774208
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#95594}
Gardeners: This may cause a slight regression for a feature that
landed behind field trial (V8GCOptimizeSweepForMutator) as a
progression. The overall situation is still a net win once launched.
Not sweeping on allocation can cause memory regressions in case where
there is no progress via tasks as we are effectively getting new
pages. We also need sweeping to return empty pages due to having finalizers.
This CL brings back sweeping on allocation instead of bailing
out depending on the limit. At the same time we introduce per-page
live byte counts which are populated during marking. The sweeper can
then sort pages accordingly and start with pages that have the most
free bytes. This results in lower time spent in sweeping on allocation
as the chance is high to get a large block or almost empty page here.
In future, we can adjust concurrent sweeper to be page agnostic which
should improve this even further.
Change-Id: I8c6d4cd037c8fb1b521d1a43606d673fe0d370a1
Bug: 333981063
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5645442
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94597}
Currently, heap snapshots represent many Blink objects as "InternalNode"
with size zero, and omit those objects entirely unless they point to
something with a more meaningful name. This improves the readability of
heap snapshots, but can hide a substantial amount of memory usage. This
CL changes the heap snapshot generator to include those InternalNodes
and their sizes if the user has enabled and checked the box titled
"Expose internals (includes additional implementation-specific
details)", because such users have explicitly opted in to see a more
detailed snapshot. The InternalNodes shown are not immediately
actionable, but there is a plausible pathway to success: InternalNodes
have a tooltip with a "learn more" link which explains how to see class
names in Chrome for Testing.
This change also includes a drive-by improvement to shrink EmbedderNode
by one pointer.
Bug: 340200025
Change-Id: Ic7b2fba8c3f45eedbc9a2fbeb33484c2c624cdaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5542948
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94083}
It will call CageBaseGlobal::Get() in Decompress(), but the base
already in the argument of "GetNextUnfinalized", we could avoid to
call Decompress() by directing decompress the pointer with the base.
Change-Id: Iffd52cb4bacee500dd634cffc3f406dc2d8143b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5384970
Commit-Queue: Wenqin Yang <wenqin.yang@intel.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93000}
Most code was using V8_TARGET_* when really this macro is used for
determining the JIT target. All of Oilpan runs on the host though, so
we should use the V8_HOST_* macros.
A side effect of this is fixing a cross-compilation issue. Previously,
when setting target_cpu=x64 on arm64, we would get write barriers in
cppgc's public API wrong because the macro override is not propagated
to the API and the information about guard pages got out of sync.
Using the host macro fixes this because it is never overriden using GN
(but only via compilers directly).
Bug: chromium:1520621
Change-Id: Iba034f53b90b6f76f24d57f584e957cdde9d2177
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5257317
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#92134}
Prepare to introduce a runtime parameter that will allow varying the
heap size if the larger cage is enabled.
Bug: chromium:1434388
Change-Id: Ie68366c16983a83cf0d342248ee7cd1bf379de61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4576492
Commit-Queue: Kevin Babbitt <kbabbitt@microsoft.com>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#88250}
AgeTable is used to track objects in old versus young generations in
Oilpan. It's currently hardcoded for a caged heap of a fixed size.
This CL allows the size of the AgeTable to be set dynamically.
Also included is a fix to AgeTableTest for a compile-time error about
stack allocation of subtle::DisallowGarbageCollectionScope. The test
now compiles again when cppgc_enable_young_generation is set.
Bug: chromium:1434388
Change-Id: I9fd1928d9cf13f0dcaf98b18d99dee54075f392e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4575883
Commit-Queue: Kevin Babbitt <kbabbitt@microsoft.com>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#88178}
Add checks for resolving the necessary trace method, finalizer, and
name method. The methods are not used and not part of the binary.
Resolving the names ensures that the mode always compiles.
Bug: chromium:1446931
Change-Id: Ibb89e11af4b42d9cf326bfaaab0c6e058d18d57a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4573670
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87943}
This CL introduces gn flag cppgc_enable_larger_cage and corresponding
When this flag is enabled, the caged heap can grow up to 16GB.
Testing: The test I would have written for this CL is to validate that
pointer compression and decompression work correctly under 3-bit shift,
which is already covered by MemberTest.CompressDecompress. I ran the
MemberTest unit tests locally with the flag enabled and confirmed that
they pass. I also ran a full CQ dry run with the flag enabled here:
https://chromium-review.googlesource.com/c/v8/v8/+/4491403
Bug: chromium:1434388
Change-Id: I7fb07c84f3a408add2a67b875acb513906b3e18c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4491284
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Kevin Babbitt <kbabbitt@microsoft.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87419}
Rewrite caged heap reservation and pointer compression/decompression in
terms of a named constant. On its own this has no functional change, but
it sets us up to vary the amount of pointer compression shift to allow
for larger heaps.
Bug: chromium:1434388
Change-Id: I1f5fcf3f168c8cde9be37fb2633e5fe8ddf9dfd0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4491283
Commit-Queue: Kevin Babbitt <kbabbitt@microsoft.com>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87387}
The linker puts CageBaseGlobal into the .data (i.e. modifiable) section
together with other potentially frequently modifiable global variables.
Make sure false sharing doesn't happen for CageBaseGlobal by storing it
in a dedicated cacheline.
Bug: chromium:1418300
Change-Id: I1ed9bce5ae61eb295a7c20b7a21b19271fa6e5bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4280186
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#86087}
Due to restrictions on device we are not able to execute code
using a JIT. However it is possible to enable it in the iOS simulator
so we can continue gathering performance data.
Bug: chromium:1413818, chromium:1411704
Change-Id: Ie370a280f439d53ba3f31ee40ff53fa87378be1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4277141
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#86004}
The function relied on passed pointers always being compressed, which
is no longer the case with subtle::UncompressedMember<>.
Bug: chromium:1412021, chromium:1412221
Change-Id: I531e41d24fcab34e527db99f8047123f254e8a74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4217411
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85623}
Some very hot getters in Blink can spend many cycles on decompression.
We're planning to optimize such paths by selectively using uncompressed
pointers.
Change-Id: I78af751c423c56010a794448450032c66f8fa244
Bug: chromium:1410145
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4191778
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85508}
Annotate slow path call for creating a new GCInfo accordingly. This
path will only hit for the first object allocation for a given type.
All subsequent allocations will use the fast path.
Bug: chromium:1408821
Change-Id: Ifc1d3491a94b30dfeee1a2c9679c64939025fefe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4161752
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85408}
Change the calling convention for the slow write barrier call to allow
callers to avoid saving caller-saved registers.
Bug: chromium:1406464
Change-Id: I314bdacb235727e0e78a192ed7cbff09e9bc6b4b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4156476
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85254}
Introduces a slim write barrier for Oilpan behind
`cppgc_enable_slim_write_barrier` that is enabled by default. The slim
write barrier only performs a single approximate global check for
whether the write barrier is needed and delegates all other checks to
a slow path call. This is beneficial in configurations that do not need
many checks for the barrier overall, i.e., configurations without
young generation. Young generation is off by default which is why this
approach is beneficial.
On Speedometer the write barrier is hit 75M times with a fast bailout
of 99.3%. Progression on Speedometer2 is somewhere around 0.2-0.5%.
The resulting code embedded in another function is only 34 bytes
compared to 128 bytes before. See attached bug for detailed assembly
snippet.
Change-Id: I6869513186e7a26104c46f1f2ac2cfa855689f64
Bug: chromium:1406464
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4152488
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85232}
Michael Lippautz
Anton Bikineev
Dominik Inführ
Leszek Swirski
Matthias Liedtke
Steinar H Gunderson
Jakob Kummerow
Omer Katz
Eva Herencsárová
Nikolaos Papaspyrou
Peter Kasting
Zhao Jiazhong
Milad Fa
Seth Brenith
wenqin.yang
Kevin Babbitt
Dave Tapuska