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}
This reverts commit d368dcf4ae.
Reason for revert: https://crbug.com/1312188
Original change's description:
> Refactor OSROptimizedCodeCache
>
> 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).
>
> Bug: v8:12161
> Change-Id: Ib34e372aa58a30c68c9c5cdd0d1da0ec3e86717c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560447
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Jakob Linke <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79687}
Bug: v8:12161, chromium:1312188
Change-Id: Ieb3a91682845a23536fdfdf3208af74b3c6585f8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564989
Auto-Submit: Adam Klein <adamk@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@{#79700}
This is a reland of commit e76ad5c6d9
Changes compared to original:
- Move invocation of LAZY_INSTANCE_INITIALIZER to a static global
variable, as some builds were failing with a function-level static.
- Drive-by: Improve documentation a bit.
Original change's description:
> [wasm-gc] Implement isorecursive canonicalization
>
> This implements isorecursive canonicalization for static types.
>
> Not implemented in this CL:
> - Runtime type canonicalization.
> - Cross-module signature canonicalization for purposes of call_indirect.
>
> Bug: v8:7748
> Change-Id: I6214f947444eea8d7b15a29b35c94c3d07ddb525
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3541925
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79665}
Bug: v8:7748
Change-Id: I493fba1906491762f7d8bae50108e3e4a743391d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560480
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79692}
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).
Bug: v8:12161
Change-Id: Ib34e372aa58a30c68c9c5cdd0d1da0ec3e86717c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560447
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79687}
- For y = x & 0xFF, we could use movzxbq y, x.
- For y = x & 0xFFFF, we could use movzxwq y, x.
- For y = x & 0xFFFFFFFF, we could use movl y, x.
- For y = x & immediate and immediate fits into uint32,
we could use andl x, immediate.
Bug: v8:12337
Change-Id: I31f04fa9058c6acabb210f0fce61ac713ed1a382
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3518913
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79668}
This implements isorecursive canonicalization for static types.
Not implemented in this CL:
- Runtime type canonicalization.
- Cross-module signature canonicalization for purposes of call_indirect.
Bug: v8:7748
Change-Id: I6214f947444eea8d7b15a29b35c94c3d07ddb525
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3541925
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79665}
Define ctors for BasicMemoryChunk, ReadOnlyPage, MemoryChunk, Page and
LargePage. We can use those with placement-new to initialize pages. We
now initialize chunks at once either for ReadOnlyPage, Page or
LargePage. Previously initialization happened in multiple locations
starting with BasicMemoryChunk::Initialize.
Adding ctors to these classes should improve debugging, since debug
info for classes without ctors was removed with the compiler flag
`-fuse-ctor-homing`.
Change-Id: Ib842bb9b1e93a6576cad8299b7c5dbfe299baa33
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545092
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79638}
This reverts commit 164a040a2a.
Reason for revert: roll failure: https://ci.chromium.org/ui/p/chromium/builders/try/cast_shell_linux/1164753/overview
Original change's description:
> cppgc: Add regression test and check for object start bitmap
>
> Access to the object start bitmap is only safe during marking until
> sweeping is started as the concurrent sweeper may clear and rebuild
> the bitmap at any time during sweeping.
>
> Adds a DCHECK and an additional test for a previously broken
> pre-finalizer scenario.
>
> Bug: chromium:1307471
> Change-Id: If67ade43f7cdad6de4720c0efeac11bfe8c22b3c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3535782
> Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79550}
Bug: chromium:1307471
Change-Id: I181e63a34eae9369184fb86112bc64e53b8bfad5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545317
Owners-Override: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79590}
This reverts commit 9e1db51817.
Reason for revert: https://chromium-review.googlesource.com/c/v8/v8/+/3535782 causes roll failures, this needs to be reverted too because it's based on it
Original change's description:
> cppgc: Add DCHECK that object start bitmap is safe to use
>
> During sweeeping/compaction the bitmap is being reconstructed and
> should not be relied on for finding object start.
> Add a DCHECK that the bitmap is fully populated.
>
> Bug: chromium:1307471
> Change-Id: I4aa414722262bb6fb169123a49fce1510a60d3ef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540680
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79575}
Bug: chromium:1307471
Change-Id: I377b8737609fff33199776dce3d997f31074c59b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3545316
Auto-Submit: Tobias Tebbi <tebbi@google.com>
Owners-Override: Tobias Tebbi <tebbi@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#79586}
During sweeeping/compaction the bitmap is being reconstructed and
should not be relied on for finding object start.
Add a DCHECK that the bitmap is fully populated.
Bug: chromium:1307471
Change-Id: I4aa414722262bb6fb169123a49fce1510a60d3ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540680
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79575}
The code is dead since migrating to jobs API.
Change-Id: Icdcc3523ffe5830ef5851cf4ea86e579841f543c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540103
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79573}
This is a reland of 6b690a6b48.
The previous version of this CL was a bit too aggressive in the
duplication of branch conditions. This caused an increase in
register pressure in some cases, thus reducing performance.
In fact, duplicating branch conditions that require an "== 0" to be
added provides no benefits. We are thus now a bit less aggressive, and
only duplicate comparisons.
Original change's description:
> Reland [compiler] Simplify "==0" branches in MachineOperatorReducer
>
> This is a reland of 48b443f692.
>
> While fixing the initial CL, we stumbled upon a few bugs that
> we had to fix:
>
> - CommonOperatorReducer and SimplifiedOperatorReducer were applied
> before and after SimplifiedLowering, but always assumed that it
> was before SimplifiedLowering, and thus had the wrong semantics
> for branches in some cases. They now have an added parameter to
> know which semantics of branch they should use.
>
> - The lowering of StaticAssert was wrong and could leave kHeapConstant
> in the assert (instead of machine Booleans).
>
> Original change's description:
> > [compiler] Simplify "==0" branches in MachineOperatorReducer
> >
> > Bug: v8:12484
> > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Owners-Override: Tobias Tebbi <tebbi@chromium.org>
> > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#79379}
>
> Bug: v8:12484
> Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79528}
Bug: v8:12484
Change-Id: I31f575a59811a83c7c1acb4c14bf5ded63a8f536
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540102
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79560}
Currently getting the following 2 errors:
```
error: reference to 'MarkingType' is ambiguous
error: reference to 'SweepingType' is ambiguous
```
Change-Id: Ia50d1b5ea8af0fcc85acb9c0dc5cfae1956cec62
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540624
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#79556}
This reverts commit 6b690a6b48.
Reason for revert: causes a few regressions here https://chromeperf.appspot.com/group_report?rev=79528
Original change's description:
> Reland [compiler] Simplify "==0" branches in MachineOperatorReducer
>
> This is a reland of 48b443f692.
>
> While fixing the initial CL, we stumbled upon a few bugs that
> we had to fix:
>
> - CommonOperatorReducer and SimplifiedOperatorReducer were applied
> before and after SimplifiedLowering, but always assumed that it
> was before SimplifiedLowering, and thus had the wrong semantics
> for branches in some cases. They now have an added parameter to
> know which semantics of branch they should use.
>
> - The lowering of StaticAssert was wrong and could leave kHeapConstant
> in the assert (instead of machine Booleans).
>
> Original change's description:
> > [compiler] Simplify "==0" branches in MachineOperatorReducer
> >
> > Bug: v8:12484
> > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303
> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> > Owners-Override: Tobias Tebbi <tebbi@chromium.org>
> > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
> > Cr-Commit-Position: refs/heads/main@{#79379}
>
> Bug: v8:12484
> Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79528}
Bug: v8:12484
Change-Id: I457464d793e9c5af8448564aa3b46be863b96fbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540148
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79552}
Access to the object start bitmap is only safe during marking until
sweeping is started as the concurrent sweeper may clear and rebuild
the bitmap at any time during sweeping.
Adds a DCHECK and an additional test for a previously broken
pre-finalizer scenario.
Bug: chromium:1307471
Change-Id: If67ade43f7cdad6de4720c0efeac11bfe8c22b3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3535782
Reviewed-by: Nikolaos Papaspyrou <nikolaos@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79550}
This is a reland of 48b443f692.
While fixing the initial CL, we stumbled upon a few bugs that
we had to fix:
- CommonOperatorReducer and SimplifiedOperatorReducer were applied
before and after SimplifiedLowering, but always assumed that it
was before SimplifiedLowering, and thus had the wrong semantics
for branches in some cases. They now have an added parameter to
know which semantics of branch they should use.
- The lowering of StaticAssert was wrong and could leave kHeapConstant
in the assert (instead of machine Booleans).
Original change's description:
> [compiler] Simplify "==0" branches in MachineOperatorReducer
>
> Bug: v8:12484
> Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Owners-Override: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79379}
Bug: v8:12484
Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79528}
.. into new virtual subclass TurbofanCompilationJob. Update all TF code
to derive from this class. Specifically, the OptimizedCompilationInfo is
TF-specific and now lives in TurbofanCompilationJob.
The motivation behind this is that Maglev now also uses this
infrastructure.
Drive-by: Replace CompilationMode with ConcurrencyMode.
Bug: v8:7700
Change-Id: Iae6d1ffd1c810e2e45cad6c9b4e43d4c82ac54a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528493
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79515}
This CL moves the call to GCTracer::StopCycle for the full GC from
Heap::CompleteSweeping full, which is called to force sweeping to
finish, to GCTracer::NotifySweepingComplete, which is called as soon
as sweeping finishes --- and symmetrically to a new method
GCTracer::NotifyCppGCCompleted, which is called as soon as sweeping
of the managed C++ heap finishes. In this way, a full GC cycle is
reported as soon as sweeping is finished both for the V8 and the C++
managed heap.
The changes introduced in this CL are essentially a partial revert of
https://crrev.com/c/3456563, fixed in such a way that when the full
GC cycle is reported, the current tracer event will be the correct
one corresponding to that cycle.
Bug: v8:12503
Bug: chromium:1154636
Change-Id: Icea07cf35a9565994e798b0500e9da72cd95f9ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497318
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@{#79470}
Modernise the RegList interface to be a proper class, rather than a
typedef to an integer, and add proper methods onto it rather than ad-hoc
bit manipulation.
In particular, this makes RegList typesafe, adding a DoubleRegList for
DoubleRegisters.
The Arm64 CPURegList isn't updated to use (or extend) the new RegList
interface, because of its weird type-erasing semantics (it can store
Registers and VRegisters). Maybe in the future we'll want to get rid of
CPURegList entirely and use RegList/DoubleRegList directly.
Change-Id: I3cb2a4d386cb92a4dcd2edbdd3fba9ef71f354d6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516747
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79460}
vector register has different register file from float register in Risc64 rvv extension.
So this cl add third FPalising kind INDEPENDENT to allocate independently simd register.
Bug: v8:11976
doc: https://docs.google.com/document/d/1UwmUwOI3eeIMYzZFRmeXmfyNXRFHNZAQ4BcN0ODdMmo/edit?usp=sharing
Change-Id: I0fb8901294b4bc44b0bee55e630b60460e42bef2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383513
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Yahan Lu <yahan@iscas.ac.cn>
Commit-Queue: Yahan Lu <yahan@iscas.ac.cn>
Cr-Commit-Position: refs/heads/main@{#79449}
Instead of using the high water mark for determining this metric, we use
a bitset for all active/used system pages on a V8 heap page. Each time
when allocating a LAB on a page, we add the pages of that memory range
to that bitset. During sweeping we rebuild that bitset from scratch and
replace it with the old one in case free pages are discarded by the GC.
We DCHECK here that the sweeper only ever removes pages. This has the
nice benefit of ensuring that we don't miss any allocations (like we
do now for concurrent allocations).
CommittedPhysicalMemory for a page is then calculated by counting the
set bits in the bitset and multiplying it with the system page size.
This should be simpler to verify and track the "real" effective size
more precisely.
One case where we are partially less precise than the current
implementation is for LABs. In order to reduce complexity we now treat
all pages of a LAB allocation as active immediately. In the current
implementation we tried to only account the actual used part of the LAB
when changing the LAB later. This is more complex to track correctly
but also doesn't account the currently used LAB in effective size.
Change-Id: Ia83df9ad5fbb852f0717c4c396b5074604bd21e9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497363
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79428}
The only user of OverrideEmbedderStackStateScope is Blink where it is
used to override stack state of top-level tasks. Adjust the behavior
here to allow using this scope broadly while still supporting explicit
garbage collection calls.
Bug: chromium:1300492
Change-Id: I78c418c5f08991bf6857147cd4a537246bfcc556
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497744
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79420}
For background and reasoning, see
https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit
This is the first step towards pulling the DefineNamedOwn operation out
of StoreIC.
Summary of the renamed identifiers:
Bytecodes:
- StaNamedProperty -> SetNamedProperty: calls StoreIC and emitted for
normal named property sets like obj.x = 1.
- StaNamedOwnProperty -> DefineNamedOwnProperty: calls
DefineNamedOwnIC (previously StoreOwnIC), and emitted for
initialization of named properties in object literals and named
public class fields.
- StaKeyedProperty -> SetKeyedProperty: calls KeyedStoreIC and emitted
for keyed property sets like obj[x] = 1.
- StaKeyedPropertyAsDefine -> DefineKeyedOwnProperty: calls
DefineKeyedOwnIC (previously KeyedDefineOwnIC) and emitted for
initialization of private class fields and computed public class
fields.
- StaDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: calls
DefineKeyedOwnPropertyInLiteral runtime function (previously
DefineDataPropertyInLiteral) and emitted for initialization of keyed
properties in object literals and static class initializers. (note
that previously the StoreDataPropertyInLiteral runtime function name
was taken by object spreads and array literal creation instead)
- LdaKeyedProperty -> GetKeyedProperty, LdaNamedProperty ->
GetNamedProperty, LdaNamedPropertyFromSuper ->
GetNamedPropertyFromSuper: we drop the Sta prefix for the property
store operations since the accumulator use is implicit and to make
the wording more natural, for symmetry the Lda prefix for the
property load operations is also dropped.
opcodes:
- (JS)StoreNamed -> (JS)SetNamedProperty: implements set semantics for
named properties, compiled from SetNamedProperty (previously
StaNamedProperty) and lowers to StoreIC or Runtime::kSetNamedProperty
- (JS)StoreNamedOwn -> (JS)DefineNamedOwnProperty: implements define
semantics for initializing named own properties in object literal and
public class fields, compiled from DefineNamedOwnProperty (previously
StaNamedOwnProperty) and lowers to DefineNamedOwnIC
(previously StoreOwnIC)
- (JS)StoreProperty -> (JS)SetKeyedProperty: implements set semantics
for keyed properties, only compiled from SetKeyedProperty(previously
StaKeyedProperty) and lowers to KeyedStoreIC
- (JS)DefineProperty -> (JS)DefineKeyedOwnProperty: implements define
semantics for initialization of private class fields and computed
public class fields, compiled from DefineKeyedOwnProperty (previously
StaKeyedPropertyAsDefine) and calls DefineKeyedOwnIC (previously
KeyedDefineOwnIC).
- (JS)StoreDataPropertyInLiteral ->
(JS)DefineKeyedOwnPropertyInLiteral: implements define semantics for
initialization of keyed properties in object literals and static
class initializers, compiled from DefineKeyedOwnPropertyInLiteral
(previously StaDataPropertyInLiteral) and calls the
DefineKeyedOwnPropertyInLiteral runtime function (previously
DefineDataPropertyInLiteral).
Runtime:
- DefineDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral:
following the bytecode/opcodes change, this is used by
DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral)
for object and class literal initialization.
- StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral_Simple:
it's just a simplified version of DefineDataPropertyInLiteral that
does not update feedback or perform function name configuration.
This is used by object spread and array literal creation. Since we
are renaming DefineDataPropertyInLiteral to
DefineKeyedOwnPropertyInLiteral, rename this simplified version with
a `_Simple` suffix. We can consider merging it into
DefineKeyedOwnPropertyInLiteral in the future. See
https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit?disco=AAAAQQIz6mU
- Other changes following the bytecode/IR changes
IC:
- StoreOwn -> DefineNamedOwn: used for initialization of named
properties in object literals and named public class fields.
- StoreOwnIC -> DefineNamedOwnIC
- StoreMode::kStoreOwn -> StoreMode::kDefineNamedOwn
- StoreICMode::kStoreOwn -> StoreICMode::kDefineNamedOwn
- IsStoreOwn() -> IsDefineNamedOwn()
- DefineOwn -> DefineKeyedOwn: IsDefineOwnIC() was already just
IsDefineKeyedOwnIC(), and IsAnyDefineOwn() includes both named and
keyed defines so we don't need an extra generic predicate.
- StoreMode::kDefineOwn -> StoreMode::kDefineKeyedOwn
- StoreICMode::kDefineOwn -> StoreICMode::kDefineKeyedOwn
- IsDefineOwn() -> IsDefineKeyedOwn()
- IsDefineOwnIC() -> IsDefineKeyedOwnIC()
- Removing IsKeyedDefineOwnIC() as its now a duplicate of
IsDefineKeyedOwnIC()
- KeyedDefineOwnIC -> DefineKeyedOwnIC,
KeyedDefineOwnGenericGenerator() -> DefineKeyedOwnGenericGenerator:
make the ordering of terms more consistent
- IsAnyStoreOwn() -> IsAnyDefineOwn(): this includes the renamed and
DefineNamedOwn and DefineKeyedOwn. Also is_any_store_own() is
removed since it's just a duplicate of this.
- IsKeyedStoreOwn() -> IsDefineNamedOwn(): it's unclear where the
"keyed" part came from, but it's only used when DefineNamedOwnIC
(previously StoreOwnIC) reuses KeyedStoreIC, so rename it accordingly
Interpreter & compiler:
- BytecodeArrayBuilder: following bytecode changes
- StoreNamedProperty -> SetNamedProperty
- StoreNamedOwnProperty -> DefineNamedOwnProperty
- StoreKeyedProperty -> SetKeyedProperty
- DefineKeyedProperty -> DefineKeyedOwnProperty
- StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral
- FeedbackSlotKind:
- kDefineOwnKeyed -> kDefineKeyedOwn: make the ordering of terms more
consistent
- kStoreOwnNamed -> kDefineNamedOwn: following the IC change
- kStoreNamed{Sloppy|Strict} -> kSetNamed{Sloppy|Strict}: only
used in StoreIC for set semantics
- kStoreKeyed{Sloppy|Strict} -> kSetKeyed{Sloppy|Strict}: only used
in KeyedStoreIC for set semantics
- kStoreDataPropertyInLiteral -> kDefineKeyedOwnPropertyInLiteral:
following the IC change
- BytecodeGraphBuilder
- StoreMode::kNormal, kOwn -> NamedStoreMode::kSet, kDefineOwn: this
is only used by BytecodeGraphBuilder::BuildNamedStore() to tell the
difference between SetNamedProperty and DefineNamedOwnProperty
operations.
Not changed:
- StoreIC and KeyedStoreIC currently contain mixed logic for both Set
and Define operations, and the paths are controlled by feedback. The
plan is to refactor the hierarchy like this:
```
- StoreIC
- DefineNamedOwnIC
- SetNamedIC (there could also be a NamedStoreIC if that's helpful)
- KeyedStoreIC
- SetKeyedIC
- DefineKeyedOwnIC
- DefineKeyedOwnICLiteral (could be merged into DefineKeyedOwnIC)
- StoreInArrayLiteralIC
- ...
```
StoreIC and KeyedStoreIC would then contain helpers shared by their
subclasses, therefore it still makes sense to keep the word "Store"
in their names since they would be generic base classes for both set
and define operations.
- The Lda and Sta prefixes of bytecodes not involving object properties
(e.g. Ldar, Star, LdaZero) are kept, since this patch focuses on
property operations, and distinction between Set and Define might be
less relevant or nonexistent for bytecodes not involving object
properties. We could consider rename some of them in future patches
if that's helpful though.
Bug: v8:12548
Change-Id: Ia36997b02f59a87da3247f20e0560a7eb13077f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3481475
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#79409}
Before a young GC, the scavenger finalizes a pending full GC sweeping,
in case there are no more running sweeping jobs, to avoid unnecessarily
pausing sweeping and then resuming it.
This CL moves this sweeping finalization from
ScavengerCollector::CollectGarbage to Heap::CompleteSweepingYoung, so
that it is also performed for the minor mark-compactor and that sweeping
is correctly attributed to the previous full GC cycle (instead of the
beginning young cycle). Furthermore, it also finalizes CppGC sweeping
if there are no more running sweeping jobs.
Bug: chromium:1154636
Change-Id: Ic9ba4803f49db32c0a539f080329f012859bc8bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3508011
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79407}
This rename better reflects that heap_base is both used in cppgc but
also V8's GC.
Bug: v8:12691
Change-Id: Ia18ecba462d1b55cee6722452ceb28b25490a066
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3506374
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79398}
Instead of returning a boolean success/failure value, the Free* methods
of the VirtualAddressSpace API now terminate the process on failure, as
this implies a bug in the caller. This is simpler than CHECKing for
success in all callers and also provides more details about the possible
cause of the failure.
Bug: v8:12656
Change-Id: I5b469ae2c564068cff74e60b7e98f6a4776a239d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3506992
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79388}
This proposal adds i32 and i64 addition, subtraction, and multiplication
to the list of constant expressions.
See https://github.com/WebAssembly/extended-const.
Bug: v8:12089
Change-Id: I23a27a54a15fd37ee1d553992ab3b355eb9d317c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497665
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79362}
This renaming was missed in
https://chromium-review.googlesource.com/c/v8/v8/+/3468577, because the
code adding these #ifdef blocks landed in-between the renaming change
being uploaded and landed.
Bug: chromium:1298417
Change-Id: I8c2e951099dafcce7e19a59e40e36f308e2ed867
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3498349
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79345}
According to the latest changes in wasm-gc, externref will be renamed
to anyref, and will be assigned as the top of the reference type
hierarchy. Since in the current wasm type system funcref is not a
subtype of anyref, subtyping is now dependent on whether wasm-gc is
enabled.
Bug: v8:7748
Change-Id: I0c0ae3dd5523e624d4490ca33d1fba4c2ae59393
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3468345
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79322}
The following histograms have been deprecated, as they are superseded
by V8.GC.Cycle.*.Young or not needed anymore (next to each, the
corresponding isolate counter):
- V8.GCScavenger (gc_scavenger)
- V8.GCScavengerBackground (gc_scavenger_background)
- V8.GCScavengeReason (scavenge_reason)
- V8.GCScavengerForeground (gc_scavenger_foreground)
- V8.GCBackgroundScavenger (background_scavenger)
- V8.GCMarkCompactor (gc_mark_compactor)
This CL removes the corresponding instrumentation in the code and the
isolate counters.
Bug: chromium:1154636
Bug: chromium:1299555
Change-Id: I62d28ff60ef47a058fe148c7855af8e2c1cc0aed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3487548
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79308}
The main change is the section name, which is now 'metadata.code.branch_hint'.
The binary format has also a couple of minor changes.
Semantics remain unchanged.
Change-Id: I056c9f672ae494979e8ea55266fa766139b71d38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3487788
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79292}
This CL refactors Heap::GCTypeTimer and Heap::GCTypePriorityTimer
and moves them to a GCTracer::RecordGCPhasesInfo class. This is
a necessary change for deprecating counters that are used for
old style GC metrics, like gc_scavenger. When all such counters
are deprecated, GCTracer::RecordGCPhasesInfo will no longer be
necessary and will be removed.
Bug: chromium:1154636
Change-Id: I04504a0f6c7a0955f4300a1c94c969aaeb23b77f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3486556
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79257}
{FreePages} is never expected to fail, and each caller wraps the call in
a CHECK macro. In order to learn more about failures, this CL moves the
CHECK inside of {::FreePages}, to fail whenever the {PageAllocator}
fails to free pages.
As a next step, I'll audit our {PageAllocator} implementations to ensure
that none of them return {false} for {FreePages}. Note that this is
already the case for the gin platform (chromium).
R=mlippautz@chromium.org
Bug: v8:12656, chromium:1299735
Change-Id: Ib61be6cc8da0110ead2db1ad005728bd061e0243
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3484321
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79248}
Custom callbacks assume that untraced pointers always point to valid,
not freed objects. They must make sure that upon callback completion no
UntracedMembers point to an unreachable object. This may not hold true
if a custom callback for an old object operates with a reference to a
young object that was freed on a minor collection cycle. To maintain
the mentioned invariant, the CL calls custom callbacks for old objects
on every minor collection cycle.
The alternative options could be:
1) Replacing all UntracedMembers with WeakMembers, since WeakMember
supports tracing and the barrier.
2) Emitting the generational barrier for UntracedMember + tracing
UntracedMember on minor collection cycles.
The first option requires changing multiple use sites and can bring some
performance regression. The second option requires changing the GC logic
and the semantics of UntracedMember.
Bug: chromium:1029379
Change-Id: I9bb89e4787daf05990feed374dceca940be7be63
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472499
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79221}
This CL refactors all remembered set logic from heap-base and
explicit-management to a new class OldToNewRememberedSet.
Bug: chromium:1029379
Change-Id: Id032b9dcc01af6f9bb9e546ed9bc6324da6d9b66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472498
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79212}
The test case was fixed in c7fbac6a72
This reverts commit 34c0f0fced.
Bug: chromium:1278780
Change-Id: If04e41a7fc1f0c744fe785a834880e598f482ef8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3401592
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79201}
On 32-bit platforms, we generally don't over-allocate backing stores
for Wasm memories. That leads to quadratic overall complexity of
repeated growth operations by a few pages each though. To fix that,
this patch introduces a small over-allocation factor: when we have
to reallocate to grow a memory, we now grow by at least 1/8th of the
memory's previous size.
Bug: chromium:1294262
Change-Id: I89b5e974c75aac78bece8fcd72fb7a2184345153
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3472496
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79193}
Weak containers are retraced if they are found through the stack using
the conservative scanner, possibly resulting in a race with the
concurrent marker.
Bug: v8:12648
Change-Id: I0936a2953e3e2151cea4191f335a091b0e334e6b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3474678
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@{#79184}
Previously, V8_OS_MACOSX was, somewhat confusingly, also used for iOS.
With this CL, V8_OS_DARWIN will be set on both macOS and iOS,
V8_OS_MACOS only on macOS, and V8_OS_IOS only on iOS.
This CL also renames V8_TARGET_OS_MACOSX to V8_TARGET_OS_MACOS and
renames platform-xnu.cc to platform-darwin.cc.
Change-Id: I4bcafc7c337586662114144f6c7ccf47d978da1f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3468577
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79167}
