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}
# Conflicts:
#include/v8-cppgc.h
(reverted v8 changes, keeping our fix. again, doesn't resolve msvc build issues.
this does not fix the issue properly. xref: 4c7c7d1a)
#src/codegen/cpu-features.h
(...did something change?)
#src/flags/flag-definitions.h
(xref: 053e54e7)
#src/heap/safepoint.cc
[-] (USE AFTER FREE) quick hack: removing a mutex guard on shared RemoveClient to temporarily mitigate a crash on deinit
well, this is fucking dumb. i think someone at google also figured out this can lead to crashing. their solution: remove the mutex with a call to AssertActive.
considering my issue was related to a dead context with everything else alive, i dont want to find out what that AssertActive is doing. reverting v8 change.
#src/objects/fixed-array-inl.h
who cares
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}
Oilpan young generation currently remembers all weak callbacks to be
processed on each GC. This is needed to support UntracedMembers in the
old space. If the old object with UntracedMember (e.g.
ActiveScriptWrappableManager) holds a pointer to a young object, the
custom weak callback must be reexecuted on each minor GC, because the
custom callback is responsible for clearing UntracedMembers.
This is not necessary for weak containers. They hold WeakMembers, for
which we issue the regular write barrier. The CL distinguishes between
callbacks for weak containers and for custom objects. This aims to
speeds up weak processing, which currently may take >10ms.
Bug: v8:13475
Change-Id: I6964a6835dc84febddbefb5e2952d57f108d1232
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4080470
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84895}
Reuse the stack object that V8 maintains via ThreadLocalTop for
CppHeap. This allows CppHeap to be migrated across threads, similar
to Isolate, when used with Locker.
Bug: v8:13207
Change-Id: I4c865f4eeb79257ed720cf46e42b27589fcf555e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4013799
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84126}
Use the `PageAllocator` that is generated/provided via
`cppgc::InitializePlatform()`.
Bug: v8:13442
Change-Id: I7f3a83ae3fe9000b430ab085929f98646585164f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4000486
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84083}
HeapHandle is an opaque handle that refers to the internal
implementation of the heap and as such should never be used by value.
Bug: v8:13429
Change-Id: I1c369911adfc623fe2c32f06b985a5d8accc0e55
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4000485
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84034}
This CL adds the following gdb commands:
cpcp <compressed-pointer> # prints compressed pointer
cpm <member> # prints member value
Bug: chromium:1373391
Change-Id: If5cc121883afbe64f4b95965a48b52647179b9f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3945108
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83633}
The attribute allows the Member to be passed around in registers. More
in the design dec: https://bit.ly/3e5tsok
Change-Id: I9c46fb2a5813f1f51f291fac6c0753f505009410
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3925708
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83550}
Now that we have all useful flags on the API side, use to them.
Bug: chromium:1056170
Change-Id: Ia849b0925a2b2c10ace30b6c2b6871bd3572da31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899306
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83238}
The split is rudimental and now is not needed at all:
- as part of the shared-cage effort we added HeapHandle pointer to the
BasePageHandle class (on the API side);
- for the value-full barrier we get HeapHandle from bitmasking the
value;
- for the value-less barrier we get it from the callback provided by the
caller.
The CL entirely removes the split and uses the single
BoundedPageAllocator. A minor note: the conservative stack scanning can
become sligthly more expensive.
Bug: chromium:1361582, chromium:1325007
Change-Id: I2a8aded3dd12037998f36341c68af8e23b0dcd88
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3899320
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83232}
https://groups.google.com/g/v8-users/c/iMFNsV_cTEA
> I am the current maintainer for Windows builds on VCPKG and Mingw-w64, the VCPKG version is probably exactly what you need, but it currently sits at 8.6.
> I am working on an update to current stable version 8.8, but if it must be 8.7 you may have to see the port and figure it out yourself.
- Feb 1, 2021
Meanwhile: https://github.com/microsoft/vcpkg/tree/master/ports/v8
> [v8] Update to version 9.1.269.39
- 14 months ago
Even fucking older than our 9.6.0 candidate builds using shid intended for 2-3 year old v8. vcpkg bros, i dont feel so good
The 2GB cage caused new OOMs on M106. While those issues are being
investigated, this CL returns the 4GB back. The pointer compression is
still enabled.
Bug: chromium:1325007, chromium:1354660
Change-Id: I4fa4fabece2910ca84913d8df201acfbdf4b26e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3865004
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82834}
Resident set size may be smaller than the recorded size in
StatsCollector due to discarded memory.
Change-Id: I7e052fc4412afc64dc1ed5be6ed7dc9271e6f9d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3855204
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82709}
Users should rely on CppHeap which is the only supported way of using
v8::TracedReference in going forward.
Bug: v8:13207
Change-Id: Idd03f458167c74b06f285bb568e5c77ad46003fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3849037
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82681}
With only 2GB reservation we can make sure that the heap allocated in
such a way, that all the pointer to it have the most significant bit
in the low halfword set. This allows us to quickly distinguish between
normal pointers and nullptr/sentinel when performing sign-extension
inside decompression.
Bug: chromium:1325007
Change-Id: Ie3a653796bb9dc875ec50103e05cb9aaf55515cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3793614
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82310}
Introduce RootVisitor and related class hierarchy to just handle
roots. This avoids the awkard definitions for roots visiation in all
the cases they are not needed.
Change-Id: Ib0912e4bf543db2ecf68caead6929c68d6afdda6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782794
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82107}
This is a reland of commit 60e9b50374
Original change's description:
> cppgc: Consistently treat sentinel pointer as live
>
> Sentinel pointers would be treated as live by the GC (through
> `HandleWeak()` but would be treated as dead when checked explicitly
> through the `LivenessBroker` in e.g. custom callbacks.
>
> Treat sentinel pointers as live consistently across all callsites
> and weak types.
>
> Change-Id: I9a4c096ddac1a111df808f3683325b55e7597eea
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782800
> 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@{#81916}
Change-Id: Ie2476345b9ea8406015a3b07bd6880c1159ede08
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779913
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@{#81975}
This reverts commit 60e9b50374.
Reason for revert: Speculative revert for https://luci-milo.appspot.com/ui/inv/build-8807661142690641489/test-results?q=conformance%2Fogles%2FGL%2FgreaterThanEqual%2FgreaterThanEqual_001_to_008.html
Original change's description:
> cppgc: Consistently treat sentinel pointer as live
>
> Sentinel pointers would be treated as live by the GC (through
> `HandleWeak()` but would be treated as dead when checked explicitly
> through the `LivenessBroker` in e.g. custom callbacks.
>
> Treat sentinel pointers as live consistently across all callsites
> and weak types.
>
> Change-Id: I9a4c096ddac1a111df808f3683325b55e7597eea
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782800
> 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@{#81916}
Change-Id: Ic1ea0655499ae2e4ae7252fda7158d809e4970ca
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3783992
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81929}
Sentinel pointers would be treated as live by the GC (through
`HandleWeak()` but would be treated as dead when checked explicitly
through the `LivenessBroker` in e.g. custom callbacks.
Treat sentinel pointers as live consistently across all callsites
and weak types.
Change-Id: I9a4c096ddac1a111df808f3683325b55e7597eea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3782800
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@{#81916}
Introduce `TraceStrongContainer()` to retain containers strongly. This
makes the use of `Trace(T*)` obsolete as all other use cases should
refer to Member overloads.
Bug: v8:13089
Change-Id: Ib0e762bf3298f1818528e45cc842d14a63f2c684
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3779680
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81864}
We will provide a replacement for raw pointers in future which should
only be used by backing stores. Any other callsite must go through
Trace(BasicMember<>).
Bug: v8:13089
Change-Id: Ibdae439b44ad94bd7af2532855be941c5334db99
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3772328
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81833}
Thread through compressed pointer into write barrier to allow to delay
compression after checking whether a write barrier is actually needed.
Change-Id: If7e6cbb69a57cc9aeeb551c11f685bace4e56c4c
Bug: chromium:1325007
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769826
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81816}
The current compression scheme defines isomorphism with respect to
relational operations (i.e. the relational operators preserve their
results on the set of compressed pointers).
In addition, provide overloads for nullptr/sentinel.
Bug: chromium:1325007
Change-Id: I476a1c59e92f5210e26142320eb03802bd11ea51
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3758143
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81706}
The increase caused a significant PMF regression on Windows. Apparently,
leaving the table in reserved state didn't eliminate the regression. The
CL returns the age size back to 1MB. The followup is to investiage and
fix the regression.
Bug: chromium:1336420
Change-Id: I56542ba4efe0fc8d08d8c5febf758384559a8860
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3758146
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@{#81705}
The operator with raw pointer allows us to avoid Member decompression,
which is more expensive than compression. It's also quite frequently
called (e.g. in HeapHashSet::find()).
The existing operator
template <...>
bool operator==(const Member<T1>&, const Member<T2>&);
was not called for
GCed* raw = ...;
member == raw;
because the compiler wouldn't deduce `T2` in `const Member<T2>` as
`GCed` when the initializer expression `raw` is of different type
(`GCed*`).
Bug: chromium:1325007
Change-Id: Ie1ee12bad28081c66f4e08a146467fd7c040bb70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3757344
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81702}
With pointer compression enabled the compiler may not inline some Member
functions on some platforms, because Member stores and loads become
slightly more expensive. Inlining is however important with pointer
compression - it allows to further optimize the code by eliminating
the global load.
Bug: chromium:1325007
Change-Id: Ia37d223e78853a8218e0b2732a3f08aa58929000
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3756141
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81648}
Shifting negative integrals is undefined behavior. The CL simply
switches to uint64_t when decompressing, which anyway results in
sign-extension (in standard terms, integral promotion must preserve the
value and the sign of the source operand).
The CL doesn't have any functional changes, the generated code is the
same. It only fixes the ubsan report.
Bug: chromium:1325007
Change-Id: I491a87b84d4e98b0225f76825dac2f9e85f168d1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3736442
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81452}
GCC doesn't have __attribute__((require_constant_initialization)). Use
it only for clang.
Bug: chromium:1325007
Change-Id: Ide5d428ed107d3244072774c0031c042ed0cee31
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3735125
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81447}
Before this CL, the caged heap was lazily initialized upon the first
call of HeapBase ctor. CagedHeap keeps a pointer to PageAllocator which
was provided from cppgc::Platform through the HeapBase ctor. This was
not generally safe: the platform is not enforced to be singleton. If it
happens to die first, then CagedHeap will have a stale pointer. The CL
fixes it simply by moving caged-heap initialization to
cppgc::InitializeProcess(), which already requires a constantly living
PageAllocator.
Bug: chromium:1338030
Change-Id: Ifb70a2db233ef36a99c919db09bed9ff9f3708ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3732107
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81422}
Since v8config.h already defines the related logic for OS detection, it
should be fine to move arch detection also there. The CL also makes
Oilpan use one of those macros to avoid discrepancy between the compiler
and custom macros (the discrepancy occurs for host tools, e.g. mksnapshot).
Bug: chromium:1336222
Change-Id: Ibe7d9116d27c3e816f4778fd4c149d8142d0f7a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3726208
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81397}
The CL fixes PMF regressions that happend after increasing
the AgeTable size.
Bug: chromium:1336529
Change-Id: If1f099b43bfcb3a8c7dd4a1c229fcb08735eb744
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3707098
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81180}
This fixes an ODR violation: the macro V8_TARGET_ARCH_ARM64 was only
visible when building V8, but not outside it. The CL implements a quick
fix that relies on compiler-based macros (__aarch64__). The proper fix
would be to make these target macros be part of the public config.
Bug: chromium:1336222
Change-Id: I46ba6c1a3cd1ac4fcd3aced60ee112e6098eba6c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3705540
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81162}
The CL aims to improve write-barrier filtering and thereby reduce the
current regressions. With 8MB AgeTable the card size becomes 512 bytes.
The memory overhead of the 8MB AgeTable is 0.2%.
Bug: chromium:1029379
Change-Id: I86f51361b9b9f0a1c22a1deef0b0540d1d9808bc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3700079
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@{#81114}
We don't need to reset the entire age table, but merely the pages that
are known to contain young objects. This must improve memory use with
generational GC enabled.
The CL is a prerequisite for another CL that'll increase the size of
the age-table.
Bug: chromium:1029379
Change-Id: Ibb5b607af20380c3936b7396b3d9767f6f17c44b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695268
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81106}
Currently, young generation assumes that all the on-heap pointers are
compressed, which is currently not the case due to the backing-store
pointers in Blink. Fixing collections to have Member<> is not easy,
because the inlined collections may have the semantics that
backing_pointer_ == inlined_buffer_;
where the inlined_buffer_ can be off-heap (e.g. on stack).
The CL introduces another type of barrier specifically for uncompressed
pointers. The followup is to use that barrier from Blink.
Bug: chromium:1029379
Change-Id: If0f519220658268dbdf915235c2e5afd7887dc0c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695358
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#81105}
