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}
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}
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}
Guard pages are 4k areas at the beginning and end of each oilpan page
(128kiB) which are meant to be inaccessible. However on ARM64 macOS, the
OS page size is 16kiB, meaning that these are not inaccessible. But we
do pay for these, as they are part of the first and last OS
page. Meaning that we effectively waste 2 * 4kiB = 6.25% of each Oilpan
page.
Since these are not serving their purpose, disable them on this
platform. Another fix could be to make the guard page 16kiB, but given
that the entire oilpan page is 128kiB, this may have adverse effects on
e.g. fragmentation.
Note that this doesn't regress security, as the regions were never
protected to begin with on this platform.
Bug: chromium:1298417
Change-Id: Iad5d05670962780e6d1eeab2bb8a331deb7aa1f3
Cq-Include-Trybots: luci.v8.try:v8_linux_arm64_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3471558
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79151}
This CL simplifies the reporting of full GC cycles and the connection
between the GC of the managed C++ heap and the managed Javascript heap.
It moves the call to GCTracer::RecordFullCycleToRecorder to be part of
GCTracer::StopCycle.
Bug: v8:12503
Bug: chromium:1154636
Change-Id: I332dbcd81d2e5bdda83f3353c6526fc18e23ebd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3456563
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@{#79075}
The generational barrier for source objects records the entire source
object to be processed later during remembered set visitation. It's
planned to be used for Blink backing stores when an inlined object (or a
range thereof) is added (HeapAllocator::NotifyNewObject(s)).
An alternative approach would be to eagerly process the inlined objects
using a custom callback. However, this requires changing Visitors to
bring slots into the context. This approach should better work for
scenarios where small ranges or single elements are added, to avoid
processing potentially large backing stores. The followup CL implements
this idea.
Bug: chromium:1029379
Change-Id: Iacb59e4b10a66354526ed293d7f43f14d8761a8f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460402
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79073}
This CL fixes a bug in the tracing of full GC cycles that was introduced
by https://crrev.com/3432211. In doing so, it refactors the tracing of
cycles by introducing an explicit state in GC tracing events, which
follows the phase within the GC cycle as perceived by the tracer. Two
new methods, (Start|Stop)AtomicPause are introduced; together with
(Start|Stop)Cycle they mark the state transitions. The existing methods
(Start|Stop)ObservablePause are now disentangled from cycles and state
transitions.
Bug: v8:12503
Bug: chromium:1154636
Change-Id: Ie4b863bc27f81dd6858103a8988874d89e6e8517
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3440663
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@{#79043}
The methods in explicit_management.h should be called via the public
variants in the subtle namespace. Calling the variants in the internal
namespace directly skips asserts and required size coversions. Doing so
may cause misuse of the api that may break GC inernals
Change-Id: I58a0f324ca1ee0839bb85eb9b53ce57785dc7b91
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3435187
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78920}
This CL adds invalidations for slots that reside in promptly freed or
shrunk storage.
Bug: chromium:1029379
Change-Id: I05e0ede55c202c952b26f452053b8777d1a2ffae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3431488
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78912}
Conceptually, a full GC cycle completes when the sweeping phase is
finished. As sweeping is performed concurrently, this happens after
Heap::CollectGarbage has returned and, at the latest, before the next
full GC cycle begins. However, an arbitrary number of young GC cycles
may happen in the meantime. Tracing information for the sweeping phase
must be added to the corresponding full GC cycle event. Until now, this
was not done correctly: this information was added to the GCTracer's
current event and could thus be attributed to a subsequent young or full
GC cycle.
This CL introduces methods GCTracer::(Start|Stop)Cycle to delimit a
cycle (still allowing for full GC cycles to be interrupted by young GC
cycles). These methods are different from (Start|Stop)ObservablePause,
which delimit the observable pause of each GC. The events of "pending"
full GC cycles are kept until they are properly amended and reported,
when the sweeping phase is finished.
This is a reland of 4ad20bff97
which was reviewed here: https://crrev.com/3404733
Bug: v8:12503
Bug: chromium:1154636
Change-Id: Icc315b53cff1f3b19b8efe49db34340a5608bcd2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3432211
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@{#78911}
This reverts commit 4ad20bff97.
Reason for revert: New test seems to be failing on TSAN/incremental marking stress (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6346/overview)
Original change's description:
> heap: Fix the tracing of GC cycles
>
> Conceptually, a full GC cycle completes when the sweeping phase is
> finished. As sweeping is performed concurrently, this happens after
> Heap::CollectGarbage has returned and, at the latest, before the next
> full GC cycle begins. However, an arbitrary number of young GC cycles
> may happen in the meantime. Tracing information for the sweeping phase
> must be added to the corresponding full GC cycle event. Until now, this
> was not done correctly: this information was added to the GCTracer's
> current event and could thus be attributed to a subsequent young or full
> GC cycle.
>
> This CL introduces methods GCTracer::(Start|Stop)Cycle to delimit a
> cycle (still allowing for full GC cycles to be interrupted by young GC
> cycles). These methods are different from (Start|Stop)ObservablePause,
> which delimit the observable pause of each GC. The events of "pending"
> full GC cycles are kept until they are properly amended and reported,
> when the sweeping phase is finished.
>
> Bug: chromium:1154636
> Change-Id: I2fbc65d4807c78656d4abc8c451043f6f86211b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404733
> 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@{#78905}
Bug: chromium:1154636
Change-Id: Id6688cfe982f9d8159c66d715b7079782a371bed
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3431489
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78908}
Conceptually, a full GC cycle completes when the sweeping phase is
finished. As sweeping is performed concurrently, this happens after
Heap::CollectGarbage has returned and, at the latest, before the next
full GC cycle begins. However, an arbitrary number of young GC cycles
may happen in the meantime. Tracing information for the sweeping phase
must be added to the corresponding full GC cycle event. Until now, this
was not done correctly: this information was added to the GCTracer's
current event and could thus be attributed to a subsequent young or full
GC cycle.
This CL introduces methods GCTracer::(Start|Stop)Cycle to delimit a
cycle (still allowing for full GC cycles to be interrupted by young GC
cycles). These methods are different from (Start|Stop)ObservablePause,
which delimit the observable pause of each GC. The events of "pending"
full GC cycles are kept until they are properly amended and reported,
when the sweeping phase is finished.
Bug: chromium:1154636
Change-Id: I2fbc65d4807c78656d4abc8c451043f6f86211b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404733
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@{#78905}
The CL does following:
1) Makes sure young generation works and tests pass;
2) Provides CollectGarbageInYoungGenerationForTesting() that is needed
to support remaining tests in Blink;
3) Moved cppgc_enable_young_generation GN flag to v8.gni to refer to it
from Blink;
4) Bails out from marking TracedReferences in UnifiedHeapMarkingState;
5) Disables (temporarily) prompt freeing for young generation;
6) Fixes remembered set visitation for nullptr|kSentinel slots.
Bug: chromium:1029379
Change-Id: I5165fa22c8a0eaa708ef7a35a9978cb12e1cb13e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3429202
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78901}
Split method into ShouldRecordRelocSlot and ProcessRelocInfo.
ProcessRelocInfo can then be reused in the write barrier and in the
future for the OLD_TO_SHARED remembered set. SlotTypeForRelocInfoMode
got moved into ProcessRelocInfo.
In addition rename and document SlotTypes. This CL does not change
behavior.
Bug: v8:11708
Change-Id: Iff712e7e6f5d3a4da64510b67b604b9e04998361
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400968
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78701}
This is a reland of 142dd775b4
Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}
Bug: chromium:1285706
Change-Id: I024e50fc0757fbcd13cb9ffde027dff55f99d25c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386600
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78631}
This reverts commit 142dd775b4.
Reason for revert: TSAN breaks: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/6113/overview
Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}
Bug: chromium:1285706
Change-Id: If1976c0356f450fc068aa4dcc39fb9a0d5417a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386598
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@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@{#78605}
https://crrev.com/c/3293410 added concurrent processing of C++ objects
found through V8 embedder fields. The CL missed that those embedder
fields are not read atomically from JS objects. The problem is that
embedder fields are only aligned to kTaggedSize on builds with pointer
compression and are as such mis-aligned for atomic ops. This is not a
problem for on-heap values as the upper 32bits are anyways computed
from the cage. Is is a problem for generic C++ values though, as they
are used with Oilpan.
This CL adds the standard marker snapshot protocol for embedder fields.
Marker:
1. Snapshot embedder fields
2. Try to mark host object
3. On success: process snapshot
Main thread:
1. On setting embedder fields mark the object black first
2. Emit a write barrier for the embedder fields
This will get simpler with the heap sandbox that uses a separate table
for embedder fields. Once the sandbox is the default configuration, we
can use it as dependency for the concurrent fast path.
Bug: chromium:1285706
Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78604}
This is a reland of 86038ecfdc
Compared to the previous CL this one is adding a TSAN suppression
for GlobalSafepoint::EnterSafepointScope. local_heaps_mutex_ of client
isolates may be locked in any order. This would be detected by TSAN as a
potential race. Add some additional DCHECKs to compensate for that
missing test coverage.
As a cleanup this CL also removes the unused methods ContainsLocalHeap()
and ContainsAnyLocalHeap() from LocalHeap.
Original change's description:
> [heap] Optimize time to reach global safepoint
>
> Initial support for global safepoints kept it simple by entering a
> safepoint for each of them one after another. This means
> time-to-global-safepoint is the sum of all time-to-safepoint operations.
> We can improve this slightly by splitting up the safepoint iteration
> into two operations:
>
> 1) Initiate safepoint lock (locks local_heaps_mutex_, arms the barrier
> and sets SafepointRequested flag for all client threads)
> 2) Block until all runnning client threads reach a safepoint
>
> We now perform operation 1) for all clients first and only then start
> with operation 2).
>
> Bug: v8:11708
> Change-Id: Iaafd3c6d70bcf7026f722633e9250b04148b3da6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310910
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78308}
Bug: v8:11708, v8:12492
Change-Id: I7087ba23c08f2d4edb9b632eef3c218fc76342e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328786
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78583}
This CL doesn't change behavior, only refactors MemoryAllocator:
* De-templatify class, MemoryAllocator is used on slow path and doesn't
really need templates for performance.
* Rename FreeMode names
* Move methods into private section of class
Change-Id: I7894fba956dcd7aa78ad0284d0924662fef4acae
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3379812
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78580}
Included in this CL:
(*) Introduce CppMarkingState that V8 should use to push references to
Oilpan. CppMarkingState allocates its own Worklist::Locals to
support concurrent updates from V8.
(*) Split Oilpan MarkingWorklist object to form a base class used by
CppMarkingState.
(*) Remove MarkerFactory and split marking initialization. Marking
worklists should already be initialized when V8 initializes
visitors. For incremental marking, this requires splitting
marking initialization and marking start.
(*) Drive-by: Mark JSObject::IsApiWrapper and
JSObject::IsDroppableApiWrapper as const.
Bug: v8:12407
Change-Id: I35cc816343da86f69a68306204675720e9b3913f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293410
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78446}
This CL renames a number of things related to the V8 sandbox.
Mainly, what used to be under V8_HEAP_SANDBOX is now under
V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
is now simply the V8 Sandbox:
V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
V8VirtualMemoryCage => Sandbox
CagedPointer => SandboxedPointer
fake cage => partially reserved sandbox
src/security => src/sandbox
This naming scheme should simplify things: the sandbox is now the large
region of virtual address space inside which V8 mainly operates and
which should be considered untrusted. Mechanisms like sandboxed pointers
are then used to attempt to prevent escapes from the sandbox (i.e.
corruption of memory outside of it). Furthermore, the new naming scheme
avoids the confusion with the various other "cages" in V8, in
particular, the VirtualMemoryCage class, by dropping that name entirely.
Future sandbox features are developed under their own V8_SANDBOX_X flag,
and will, once final, be merged into V8_SANDBOX. Current future features
are sandboxed external pointers (using the external pointer table), and
sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
because they are encoded as offsets). This CL then also introduces a new
build flag, v8_enable_sandbox_future, which enables all future features.
Bug: v8:10391
Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78384}
Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo,
which stores a couple of pointers and most importantly the Zone and
AstValueFactory of the parse. This allows the Zone and AstValueFactory
to be reused across multiple parses, rather than re-initialising
per-Parse.
With this, we can amend the LazyCompileDispatcher to initialise one
LocalIsolate, Zone and AstValueFactory per background thread loop,
rather than one per compile task, which allows us to reduce per-task
costs and re-use the AstValueFactory's string table and previous String
internalizations.
Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78289}
Checks whether a Persistent is used from the creation thread on slow
path allocations. In practice, these currently happen every 256
Persistent allocations. This is a best effort check that may help to
flush out issues that are missed with DCHECK builds.
Bug: chromium:1276570
Change-Id: Ia868ca436341b1b5ef427d5b3ec04926c1394e41
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318658
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78276}
This interface is meant to eventually replace the existing
v8::PageAllocator interface. Beyond general refactoring of the
PageAllocator APIs, the new interface now supports the concept of
(contiguous) address space reservations, which previously had to be
implemented through page allocations. These reservations now make better
use of provided OS primitives on Fuchsia (VMARs) and Windows
(placeholder mappings) and can be used to back many of the cages and
virtual memory regions that V8 creates.
The new interface is not yet stable and may change at any time without
deprecating the old version first.
Bug: chromium:1218005
Change-Id: I295253c42e04cf311393c5dab9f8c06bd7451ce3
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301475
Commit-Queue: Samuel Groß <saelo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78235}
This allows the embedder to determine whether some function has been
called from a destructor.
See discussion in
https://crrev.com/c/3302810
Bug: chromium:1273928
Change-Id: Icb5d98eff777574488a7d6de5e693c502c2fb53e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3303793
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78113}
... and thus avoid the need for special handling of objects located
in external code space.
This will also allow making HeapObject::IsBlah() checks faster when
external code space is enabled.
Bug: v8:11880
Change-Id: I12d07c05451ff198f0a6182d9b5849f76015e7fb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300140
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78104}
Unify parse post-processing between main-thread and background-thread
parsing, now that we have LocalIsolate and can Internalize on background
threads.
As part of this, simplify the LocalIsolate parking pattern to explicitly
park during ParseOnBackground, rather than being implicitly parked when
ParseOnBackground is called. This reduces the amound of scoping needed
in the BackgroundCompileTask::Run method.
Change-Id: Ifdb128b763129bda78bd1bae89dac1c62f872350
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277876
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77872}
Adds support for aborting compaction when finalizing with stack:
- never_compact_with_stack: All pages are aborted;
- never_compact_code_space_with_stack: Only code space pages are
aborted;
This flags allow simulating a worst case where a stack cannot
be considered precise, or evacuation candiate is refered to from
a stack slot that V8 has no info for.
Bug: v8:12251
Change-Id: Ice24ac87a985b8ecf7b5cbb5c106ad4a3ae1944b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173682
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77792}
Explicit write barriers for internal fields are deprecated as they are
automatically emitted by V8.
Depends on:
https://crrev.com/c/3263924
Bug: v8:12356
Change-Id: I171ba5b42a6570ce52e2e2ea1b7c1029d5a8a3a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3263888
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77772}
Internal fields are used for implementing edges to C++ objects in
Oilpan. When setting the fields on a JS API object, we should also
emit a write barrier for this edge.
This mechanism replaces the explicit write barrier in V8's API which
is provided through `JSHeapConsistency::*`.
The internal barrier should also be slightly faster as it doesn't
require any API calls.
Bug: v8:12356
Change-Id: I639d18141acfb910d0ded8d987d8a0916e25431d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257709
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77749}
Adjust WATCHLISTS to only send out updates to those testfiles as part
of notifying oilpan-reviews+v8@.
Change-Id: Ib877f0353ea2b2d1ac06c93d450145dbeb6fcc66
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260517
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77713}
Remove the concept of JobId from LazyCompileDispatcher, and make SFIs
the canonical id for these jobs.
This has several consequences:
* We no longer split enqueing a job and registering a SFI with that
job. We did this previously because we could not allocate SFIs in
the Parser -- now with LocalHeap we can, so we do.
* We remove the separate Job vector, and make the SFI IdentityMap
hold pointers to Jobs directly. This requires a small amount of
extra care to deallocate Jobs when removing them from the map,
but it means not having to allocate new global handles for jobs.
* The SFI is passed into the BackgroundCompileTask instead of the
script, so our task finalization doesn't need the SFI anymore.
* We no longer need to iterate ParallelTasks after compiling (to
register SFIs), so we can get rid of ParallelTasks entirely and
access the dispatcher directly from the parser.
There are a few drive-bys since we're touching this code:
* Jobs are move to have a "state" variable rather than a collection
of bools, for stricter DCHECKing.
* There's no longer a set of "currently running" jobs, since this
was only used to check if a job is running, we can instead inspect
the job's state directly.
* s/LazyCompilerDispatcher/LazyCompileDispatcher/g
Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77712}
Currently, in the following struct
struct LayoutObject : GarbageCollected<>, MixinA, MixinB {};
the subobject that corresponds to the first base GarbageCollected<>
always takes up some space (one word). The empty-base-optimization
doesn't happen because the second base (MixinA) has the same subobject
as the first base (GarbageCollected), which is the most parent class
GarbageCollectedBase. The compiler can't "merge" them because it must
guarantee that distinct objects of the same type have distinct
addresses.
The attribute [[no_unique_address]] doesn't work for base classes,
unfortunately (but is a good idea for a Standard proposal). As a
solution, the CL simply removes GarbageCollectedBase.
Bug: chromium:1260797
Change-Id: I415b10a5fbcebce3d6ee97b8870ea9ae90f383a8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259654
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77693}
This is a reland of 35a6eeecfa
Reland fixes:
* Add a SharedFunctionInfo::CopyFrom to encapsulate updating the SFI
from the placeholder. This now includes copying scope_info (which
wasn't included in the original CL and caused some of the issues)
* Make sure that LocalHandleScope is initialised only inside of
UnparkedScope (fixed TSAN issues)
* Clean-up: Don't add `script_` to ParseInfo, but instead pass it
separately to Parser. Eventually we'd ideally get rid of ParseInfo
entirely (splitting it into input and output) so let's not add more
fields to it. Reverts changing CreateScript to InitializeScript.
Original change's description:
> [off-thread] Allow off-thread top-level IIFE finalization
>
> Allow off-thread finalization for parallel compile tasks (i.e. for top-
> level IIFEs).
>
> This allows us to merge the code paths in BackgroundCompileTask, and
> re-enable the compiler dispatcher tests under the off-thread
> finalization flag. Indeed, we can simplify further and get rid of that
> flag entirely (it has been on-by-default for several releases now).
>
> Change-Id: I54f361997d651667fa813ec09790a6aab4d26774
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226780
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77615}
Change-Id: If1a5b14900aa6753561e34e972a293be0be9a07d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256692
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77676}
- Fix definition and declaration of noexcept methods not matching
- Disable test using deprecated APIs. Only having clang coverage is
okay here.
Change-Id: I412d0b0087b2858fb72b0365b94b82ebc13462de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256693
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77665}
This reverts commit 35a6eeecfa.
Reason for revert: TSAN failures like https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN/39084/overview
Original change's description:
> [off-thread] Allow off-thread top-level IIFE finalization
>
> Allow off-thread finalization for parallel compile tasks (i.e. for top-
> level IIFEs).
>
> This allows us to merge the code paths in BackgroundCompileTask, and
> re-enable the compiler dispatcher tests under the off-thread
> finalization flag. Indeed, we can simplify further and get rid of that
> flag entirely (it has been on-by-default for several releases now).
>
> Change-Id: I54f361997d651667fa813ec09790a6aab4d26774
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226780
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77615}
Change-Id: I6752470eebd594bad92c7cf4e58dbe5bac53598c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3255667
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Owners-Override: Shu-yu Guo <syg@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#77631}
Allow off-thread finalization for parallel compile tasks (i.e. for top-
level IIFEs).
This allows us to merge the code paths in BackgroundCompileTask, and
re-enable the compiler dispatcher tests under the off-thread
finalization flag. Indeed, we can simplify further and get rid of that
flag entirely (it has been on-by-default for several releases now).
Change-Id: I54f361997d651667fa813ec09790a6aab4d26774
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226780
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77615}
Test still fails after the previous fix.
No-try: true
Bug: v8:11933
Change-Id: I55100631e6f168728075234bddc6f9fd558c1e89
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3251169
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77605}
Bug: v8:12165
Change-Id: I54c7b429708a2d6a3c4db89911b9b69fa4a5a41a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3250640
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77600}
TracedReferenceBase use (traced) global handles to implement the
referencs. Provide a write barrier in the corresponding handle
methods. Doing so
- avoids bugs by having embedders taking care of write barrier
management.
- speeds up the barrier as it is better integrated in the handle
methods.
Drive-by: We don't need write barriers on initializating stores.
Bug: v8:12165
Change-Id: Ie49cc3783aeed576fd46c957c473c61362fefbf2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247039
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77593}
v8_enable_v8_checks has very little coverage outside of V8 itself.
Move pointer verification checks behind DEBUG so that they fire in
regular debug or dcheck_always_on builds.
Change-Id: Ib2803240dd996f4223e403d20e927aff2955afbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3242006
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77534}
Marking verification should only process young generation objects when
verifying the marking state of a young generation garbage collection.
Bug: v8:12324
Change-Id: I01db261437ec5c42ddb6c79c44e31b5fe0e536d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231343
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77518}
... when the v8_enable_external_code_space build flag is enabled.
Bug: v8:11880
Change-Id: I754c6229dcd25f81ef6dfbedc5885ac025c0aeff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3164458
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77479}
This is a reland of 929b83fb7b
This version of the CL also fixes initialization of the
marking_barrier_ in the LocalHeap constructor.
This CL also got rebased on Victor's CL in https://crrev.com/c/3229361.
It added a code_space_allocator_ in LocalHeap which needs to be
initialized a bit later on the main thread as well.
Original change's description:
> [heap] Attach to shared isolate after setting up main thread
>
> Attach to the shared isolate after the main thread was set up. Otherwise
> it could happen that a shared GC initiated from another isolate might
> see no threads are running and performs the safepoint operation in the
> middle of isolate deserialization.
>
> We use DisallowSafepoints to check that the isolate doesn't join a
> global safepoint before deserialization is complete. DisallowSafepoints
> used to prevent only invocations of Safepoint() but was updated to
> also prevent Park() and Unpark() invocations. Each state change could
> cause the thread to reach a safepoint, which would allow a shared GC
> to run.
>
> We now also DCHECK that every isolate has at least one local heap and
> that shared collections aren't started before deserialization is
> complete.
>
> Bug: v8:11708
> Change-Id: Iba3fb59dd951d5ee4fc9934158062287302fc279
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3221157
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77424}
Bug: v8:11708
Change-Id: I7d44e4a5f76cc09092c2444cede10e9331222c1d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229361
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77448}
Consider in-construction keys as live during the final GC pause.
Bug: chromium:1259587
Change-Id: Ia8c05923db6e5827b68b17a51561fbc8b2c4b467
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3221153
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77386}
Adds support for double-word aligned, i.e., 8 bytes on 32-bit
platforms and 16 bytes on 64-bit platforms, objects in Oilpan.
Changes:
- Adds generic alignment APIs and overrides.
- Internal logic to support double-word aligned allocations on LABs.
- Adjusts natural alignment of large objects to follow double-word.
- Adds a new static_assert() that suggests users file a bug if higher
alignment is required.
- Statically checks that no allocations with non-default alignment
target custom spaces that support compaction.
Bug: v8:12295
Change-Id: I05766ce2349055d5d78b68919be00e7ee91d5505
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3218150
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77348}
Allocate code range close to binary (<2GB) when pointer compression is
disabled. And enable short builtin calls if it succeeds.
Bug: v8:12045, v8:11527
Change-Id: I1a9d635b243337980fd75883d9802bc0cee75e43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069457
Commit-Queue: Hao A Xu <hao.a.xu@intel.com>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77248}
The checks for assignemnts to member during prefinalizers assumed the
slot has to live. It was assumed that if a slot is dead then we would
not be updating it.
Prefinalizers are allowed to touch dead objects and thus are techincally
allowed to write to dead slots. Such writes are usually redundant (the
object will be swept soon anyway) but are not always easy to get rid of.
Bug: chromium:1255152, v8:11749
Change-Id: I57e143abd53d434c3198616909c506eb70d8944b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199800
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77208}
If processing the marking worklists found new ephemeron pairs, but
processing the existing ephemeron pairs didn't mark new objects, marking
would stop and the newly discovered ephemeron pairs would not be
processed. This can lead to a marked key with an unmarked value.
Bug: chromium:1252878
Change-Id: I0f158f6f64490f1f06961520b4ba57fa204bd867
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199872
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77197}
Instead of explicitely splitting the cage into two separate regions, we
now just create a single BoundedPageAllocator to manage the entire
address range of the cage, then allocate the first 4GB for the pointer
compression cage.
Bug: chromium:1218005
Change-Id: I02c53ca8b6dda9074ae6caccc74c32bd6271d4d2
Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162044
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@{#76900}
HeapBase::Terminate must consider newly created CrossThreadPersistent
when evaluating whether to conitnue the loop. This allows for catching
one off creations in destructors but will still crash for
>kMaxTerminationGCs chains.
Bug: chromium:1245519
Change-Id: I264f1b8f0de9f0bfeb66ca6b14c41faf15e4340c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3140606
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76659}
Prefinalizers have long been forbidden to allocate.
This restriction often proved problematic and has caused several
issues in the past.
This CL adds support for allowing allocations in prefinalizers.
At the start of prefinalizer invocations we clear the linear
allocation buffers, such that all allocations go through the slow
path for allocation. The slow path checks whether prefinalizers
are currently being invoked and marks the newly allocated object
if they are (i.e. black allocation during prefinalizers).
The new behavior is disabled by default and can be enabled by
setting the cppgc_allow_allocations_in_prefinalizers gn arg to true.
Bug: chromium:1056170
Change-Id: Ib86e780dcff88fa7b0f762ac2ab83c42393d33af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097877
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76606}
Sets up custom OOM handling in cppgc and installs a handler that
redirects to V8's handler when running with unified heap.
Bug: chromium:1242180
Change-Id: I68b7038a3736cc0aa92207db2c3d129a9ff68091
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3116253
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76467}
This is a reland of d1b27019d3
Fixes include:
Adding missing file to bazel build
Forward-declaring classing before friend-classing them to fix win/gcc
Add missing v8-isolate.h include for vtune builds
Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}
Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
Bug: v8:11965
Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76460}
This reverts commit d1b27019d3.
Reason for revert: Broke vtune build, tsan build and possibly others
Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}
Bug: v8:11965
Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76428}
This moves every single class/function out of include/v8.h into a
separate header in include/, which v8.h then includes so that
externally nothing appears to have changed.
Every include of v8.h from inside v8 has been changed to a more
fine-grained include.
Previously inline functions defined at the bottom of v8.h would call
private non-inline functions in the V8 class. Since that class is now
in v8-initialization.h and is rarely included (as that would create
dependency cycles), this is not possible and so those methods have been
moved out of the V8 class into the namespace v8::api_internal.
None of the previous files in include/ now #include v8.h, which means
if embedders were relying on this transitive dependency then it will
give compile failures.
v8-inspector.h does depend on v8-scripts.h for the time being to ensure
that Chrome continue to compile but that change will be reverted once
those transitive #includes in chrome are changed to include it directly.
Full design:
https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
Bug: v8:11965
Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76424}
HAS_PROGRESS_BAR is set after page initialization at which point all
flags are assumed to be immutable while a GC is running.
Separating out the progress bar from flags allows setting it lazily at
allocation time.
Bug: v8:11915
Change-Id: I48a877e0e80d583d7a0fadef2546fc70417806e7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085268
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76382}
This reverts commit edcc8ff5b5.
Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Blink%20Linux%20Debug/10806/overview
A prefinalizer is creating a WeakMember from a raw pointer to a dead object for checking whether it is in a set.
Original change's description:
> cppgc: Enable checks for assignments in prefinalizers
>
> Bug: v8:11749
> Change-Id: Ic027f732030fb6a2befeffeca9db2eacfd0830a5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3099953
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Omer Katz <omerkatz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76370}
Bug: v8:11749
Change-Id: I0c90f232df9ae363f05f8b9ba26c2a7eede8a269
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3106646
Auto-Submit: Omer Katz <omerkatz@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@{#76377}
Adds a heap verification GN arg to gate the marking verifier and live
bytes verification on. The flag may be used in future for other more
expensive checks as well.
Currently, the flag is automatically enabled in dcheck_is_on and debug
builds.
The change enables live bytes verification for the library in regular
debug builds which may flush out issues.
Bug: v8:11785
Change-Id: I0f41bc0d76ebea9f6a8c9315c947598015ee5d68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097868
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76325}
When this is enabled, v8 reserves a large region of virtual address
space during initialization, at the start of which it will place its 4GB
pointer compression cage. The remainder of the cage is used to store
ArrayBuffer backing stores and WASM memory buffers. This will later
allow referencing these buffers from inside V8 through offsets from the
cage base rather than through raw pointers.
Bug: chromium:1218005
Change-Id: I300094b07f64985217104b14c320cc019f8438af
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010195
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Samuel Groß <saelo@google.com>
Cr-Commit-Position: refs/heads/master@{#76234}
nullptr objects are considered alive to allow weakness to be used from
stack while running into a conservative GC. Treating nullptr as dead
would mean that e.g. custom collectins could not be strongified on
stack.
Bug: chromium:1231286
Change-Id: Ibeddef18fcbae366c3f54304bf36b75c47bd74ff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085280
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76229}
Cppgc reports used bytes statistics to CppHeap. CppHeap should forward
the stats to v8. However, if we are not allowed to trigger a GC, CppHeap
will cache the stats until the reporting.
On GC finalization, CppHeap resets v8's counters to the current marked
bytes counter.
If the last reported stats before GC finalization are cached, CppHeap
doesn't clear the cache on GC finalization. On the next stats reporting,
CppHeap will report the cached values. If the cache is a decrease that
is larger than the current marked bytes, a DCHECK in
LocalEmbedderHeapTracer::DecreaseAllocatedSize will fail.
Bug: chromium:1056170
Change-Id: I47933abc3e5f5c4a91454e0ec03adde5cf61d8fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056970
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75986}
Allow CrossThreadPersistent and its weak form to access ASAN poisoned
memory from the GC entry points.
In general, payloads of to-be-finalized objects are poisoned until the
finalizer actually runs to avoid accidentally touching that payload.
In the case of cross-thread handles, these may need to be cleared by a
different thread before the finalizer actually runs. In order to clear
those references, the slot needs to be unpoisoned.
This is issue is ASAN-only and does not affect production or other
debug builds.
Bug: chromium:1230599, chromium:1056170
Change-Id: If4d0808953047319b02653821abbb5c638084dc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040845
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75846}
The concurrent sweeper destroyed large pages directly in case no
finalizer was needed during sweeping. This is unsafe as the logic of
BasePage::Destroy is not concurrency safe.
Bug: chromium:1056170, chromium:1231053
Change-Id: I8ae9b27b916f8c4aee0c239c7ac8f2ec61d92c56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041671
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75842}
So far, discarded size was maintained by the sweeper but not wired up
anywere.
Changes in this patch:
- Wire up resident size in heap statistics collection.
- Fix bugs in reporting committed and resident size.
- Sweeper test: Enforce some internal details. The details should not
not be checked broadly but be kept as a detail to the sweeper
itself.
- Stats collection: Test that committed and resident set size are
reported and differ after discarding GCs.
Bug: chromium:1056170
Change-Id: Icf8871c7ea3b28253233485c736b2ca4816fd6f2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3020971
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/master@{#75684}
Splits FLAG_lazy into
- FLAG_lazy for main-thread compiled scripts/modules
- FLAG_lazy_streaming for streamed scripts
- FLAG_lazy_eval for eval
This allows us to evaluate the impact of non-lazy compilation for streamed
scripts.
Change-Id: I8a362ea184e0afd3aa7cdb11a7eab5b7497a4691
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999090
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75518}
This is a reland of edab873071
It was speculatively reverted but the issue turned out to just be slow
tests.
Original change's description:
> Fix -Wimplicit-int-float-conversions.
>
> Bug: chromium:989932
> Change-Id: Ief917b023cb079f5ff87dc8963d74f225d074d7a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2989096
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Auto-Submit: Peter Kasting <pkasting@chromium.org>
> Commit-Queue: Peter Kasting <pkasting@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75413}
Bug: chromium:989932
Change-Id: Iec8ac8ee32705c6a699a2df2f292ffe07cde99f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2994802
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75443}
Set stack start as otherwise TracedReference from stack would not be
kept alive.
Bug: chromium:1220744, chromium:1056170
Change-Id: I99d54ac44b3f7cb4aa9732eb9260b918193a68e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972728
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75249}
The adding of base:: was mostly prepared using git grep and sed:
git grep -l <pattern> | grep -v base/vector.h | \
xargs sed -i 's/\b<pattern>\b/base::<pattern>/
with lots of manual clean-ups due to the resulting
v8::internal::base::Vectors.
#includes were fixed using:
git grep -l "src/utils/vector.h" | \
axargs sed -i 's!src/utils/vector.h!src/base/vector.h!'
Bug: v8:11879
Change-Id: I3e6d622987fee4478089c40539724c19735bd625
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75243}
* Skip 8 tests that timeout due to the low-performance of current MMTk non-moving GC.
- This will be enabled after TPH performance issues are addressed.
* Skip 2 new tests that creates a second isolate -- TPH does not support it at the moment.
* Skip 1 test that expects concurrent sweeping behavior of cppgc.
Bug: v8:11641
Change-Id: If86cdcc303b01536d278368886bb30d91da5c5c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2909692
Auto-Submit: Wenyu Zhao <wenyu.zhao@anu.edu.au>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75036}
This will allow Fuchsia tests to be run on v8 CI
Bug: v8:11843, chromium:934932
Change-Id: I516329d8f29d9c94d46aa010fa729fa3ca0993ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2935024
Commit-Queue: Chong Gu <chonggu@google.com>
Auto-Submit: Chong Gu <chonggu@google.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74993}
This is a reland of b0c70710a4
The first CL got reverted because of build errors. This CL replaces the
remaining usage of is_local_space() with is_compaction_space().
Supposedly this was a leftover because https://crrev.com/c/2928189
landed at roughly the same time.
Original change's description:
> [heap] Remove unused LocalSpace class
>
> LocalSpace was introduced for off-heap spaces with concurrent bytecode
> compilation finalization. However, finalization ended up using
> LocalHeap for concurrent allocations. LocalSpace is therefore unused
> and can be removed.
>
> This CL removes LocalSpace and renames all mentions of local space to
> compaction space. Compaction space was the only local space left.
>
> Change-Id: I12a8a2724f777a77ddb9957fe2d8e89febfebbaf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930169
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74914}
Change-Id: I993c47fe85f4140f5d6137afde2653a48047cafb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2939983
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74957}
This reverts commit b0c70710a4.
Reason for revert: Lots of compile errors.
Original change's description:
> [heap] Remove unused LocalSpace class
>
> LocalSpace was introduced for off-heap spaces with concurrent bytecode
> compilation finalization. However, finalization ended up using
> LocalHeap for concurrent allocations. LocalSpace is therefore unused
> and can be removed.
>
> This CL removes LocalSpace and renames all mentions of local space to
> compaction space. Compaction space was the only local space left.
>
> Change-Id: I12a8a2724f777a77ddb9957fe2d8e89febfebbaf
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930169
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74914}
Change-Id: I3a654da0ddb556c1fb8767f8401ecd3b46786bea
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933140
Auto-Submit: Clemens Backes <clemensb@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/master@{#74915}
LocalSpace was introduced for off-heap spaces with concurrent bytecode
compilation finalization. However, finalization ended up using
LocalHeap for concurrent allocations. LocalSpace is therefore unused
and can be removed.
This CL removes LocalSpace and renames all mentions of local space to
compaction space. Compaction space was the only local space left.
Change-Id: I12a8a2724f777a77ddb9957fe2d8e89febfebbaf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2930169
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74914}
This CL does 2 things:
1) Implements forwarding of histogram reporting from cppgc to v8 via
CppHeap.
2) Establishes the pipeline in GCTracer for sending the histograms to
the embedder.
Currently only cppgc histograms are populated.
See crrev.com/c/2916956 for usage.
Bug: chromium:1154636
Change-Id: I8150116f757e105d0dfac96a3f6e7dd95717f5bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917033
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74830}
Switches internals of BasePage and some getters to references that are
guaranteed non-null.
Bug: v8:11822
Change-Id: I484c4451720dc7e04f8b89dbe4fef03a3eaf817e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2917038
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74756}
Check that the marked bit of an object is set if assigned during a
prefinalizer to a Member in a live object or a Persistent.
Bug: v8:11749
Change-Id: I993c0d226a4157698591e1f7bc0c55e5c79239b6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897093
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74672}
The barrier just re-added a black object to the worklist (making it
gray) which results in double-accounting live bytes.
Trace directly as the barrier is not widely used.
Bug: chromium:1056170
Change-Id: I06a55c13f6e82652ad1939a12c4e23f3a3ebd3fd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2904212
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74668}
The marking verifier already traverses the whole heap using page
iteration. Add an option to allow checking that the verifier pass
finds the same amount of live bytes as the marker traversal.
Bug: chromium:1056170
Change-Id: I1dc4cd0c04147b8cd3e3eb7678276b665336e615
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2902724
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74630}
Conceptually, Oilpan uses tri-color marking even though the
implementatin only uses a single mark bit. The difference between gray
and black is represented by the fact that an objet is contained within
a worklist.
Live bytes are accounted on gray->black transition and must only
happen once. This is generally implemented when retrieving an object
from the work list and processing it.
For weak containers this CL fixes the following issues:
1. Weak containers that are strongified during stack scanning were
double accounted as they were just added to the marking worklist.
Instead, directly process them during stack scanning.
2. Accounting was missing in case of purely weak collections without
ephemeron tracing. In such a case, the backing store would not be
added to a worklist and be considered as black immediately. The fix
is to directly account the marked bytes in such a scenario.
Bug: chromium:1056170
Change-Id: I350ae1b90ad1753d024a3ce33fc3ec3126a2095d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2900661
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74629}
Create verification state on first assignment and check that
the reference slot is contained within the values heap if it
is an on-heap reference.
Bug: chromium:1056170
Change-Id: I0ce0e2bbd751186429950bb4f6bad97b273b3128
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2887509
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74607}
ObjectView abstracts Start/End/Size of an object over the different
internal representations (HeapObjectHeader and LargePage).
Bug: chromium:1056170
Change-Id: I4e888f907fff94c1b02d5e21b4ec3f4a78a471f8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2892081
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74594}
Replaces Payload* terminiology with Object* terminology.
HoH::ObjectSize = just the object, without the header.
HoH::AllocatedSize = both the object and the header.
Payload terminology is retained only for pages.
Bug: chromium:1056170
Change-Id: I568a324ae8728f098be642b024493c375ec873cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2892079
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74538}
We would use a payload size of 0 and end up walking up the stack till
we crash.
Bug: chromium:1056170
Change-Id: I12a69ada24697faaf05e2f4ab210045d54cf34e5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891657
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74537}
Member is sometimes still used from off-heap storage which prohibits
getting the heap from the Member's slot address.
Bug: v8:11756
Change-Id: I61658ce07a8b02a8c400232ff21c75f0d8b95dcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2886879
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74496}
This is a reland of 7458e67c4e
Original change's description:
> cppgc: Implement basic Member and Persistent checks
>
> Adds check for
> - same heap on assignment
> - header and containment
>
> The verification state is eagerly created for on-heap Member
> references using caged heap and lazily created on first assignment for
> all others.
>
> Bug: chromium:1056170
> Change-Id: I38ee18eeb7ac489f69a46670cc5e5abe07f62dfa
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878745
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74449}
Bug: chromium:1056170
Change-Id: I9cecfcf7ba2cb70650fd51f345fbf740b96ff6ba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2882804
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74468}
This reverts commit 7458e67c4e.
Reason for revert: Crash on windows https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20debug/37698/overview
Original change's description:
> cppgc: Implement basic Member and Persistent checks
>
> Adds check for
> - same heap on assignment
> - header and containment
>
> The verification state is eagerly created for on-heap Member
> references using caged heap and lazily created on first assignment for
> all others.
>
> Bug: chromium:1056170
> Change-Id: I38ee18eeb7ac489f69a46670cc5e5abe07f62dfa
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878745
> Reviewed-by: Omer Katz <omerkatz@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74449}
Bug: chromium:1056170
Change-Id: I466522a7d879560c99dabbd96c3b097894743a87
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2880149
Auto-Submit: Zhi An Ng <zhin@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/master@{#74450}
Adds check for
- same heap on assignment
- header and containment
The verification state is eagerly created for on-heap Member
references using caged heap and lazily created on first assignment for
all others.
Bug: chromium:1056170
Change-Id: I38ee18eeb7ac489f69a46670cc5e5abe07f62dfa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878745
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74449}
The application may itself change ASAN poisoning which conflicts with
the memset() right before poisoning memory.
This is relevant for destructors but also when invoking Resize() on an
object that uses ASAN container annotations. Annotations are hard to
adjust for the embedder as it is not clear upfront whether the call will
succeed.
Bug: chromium:1056170
Change-Id: I7f719e4130ba6149494a45f220a341658970bc6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878733
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74431}
gcc complains about the 'extern "C"' going after attributes.
Bug: v8:11710
Change-Id: If253c73bdfb2473267511d556950da37b80f790b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2877797
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74426}
Destroyed large pages can be reallocated before the OS get a chance to
reclaim and clear them. In such cases we will get non-zero memory in a
newly allocated page.
Normal pages are not affected since they are kept in page pools instead
of being freed.
Fix by explicitly clearing the payload when destroying a large page.
Bug: chromium:1056170, chromium:1206274
Change-Id: I6436302f50b8f0b4ef41288425bf464b0eb52d5f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874404
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74418}
The change broke msvc build. This CL fixes it.
Original change description:
> This reverts commit 97b4ed7438.
>
> Microsoft x86_64 ABI considers XMM6-XMM15 as non-volatile
> (callee-saved), which means that the compiler can store pointers in them.
> We need to make sure they are pushed onto the stack inside the stack
> scanning trampolines.
> Bug: v8:11710
> Change-Id: Ida804fe49d3d3b6f179ec276903a42ec8d3d86be
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2865745
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Auto-Submit: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74376}
Bug: v8:11710
Change-Id: I5357ceffe4dce5c570a15d8be86d6db11926e88c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2876846
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74416}
- Take HeapHandle& parameter to allow a use case of free() on an already
dead object during sweeping.
- Change free() from T* to T& which forces an object and allows the
caller to place the nullptr check before retrieving a heap handle.
Bug: chromium:1056170
Change-Id: I80689d27d3abe410d177cd8c86b31ff2fe579a77
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874461
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74387}
This reverts commit 305aa12f8c.
Reason for revert: Breaks MSVC compilation: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/17718/overview
Original change's description:
> cppgc: Save xmm registers on the stack
>
> Microsoft x86_64 ABI considers XMM6-XMM15 as non-volatile
> (callee-saved), which means that the compiler can store pointers in them.
> We need to make sure they are pushed onto the stack inside the stack
> scanning trampolines.
>
> Bug: v8:11710
> Change-Id: Ida804fe49d3d3b6f179ec276903a42ec8d3d86be
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2865745
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Auto-Submit: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74376}
Bug: v8:11710
Change-Id: I9593e55b5c935619a6707f3c00f9ac295475b30d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874462
Auto-Submit: Clemens Backes <clemensb@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/master@{#74379}
Microsoft x86_64 ABI considers XMM6-XMM15 as non-volatile
(callee-saved), which means that the compiler can store pointers in them.
We need to make sure they are pushed onto the stack inside the stack
scanning trampolines.
Bug: v8:11710
Change-Id: Ida804fe49d3d3b6f179ec276903a42ec8d3d86be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2865745
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74376}
AtomicCtorTag is needed by Blink to force atomic initialization of
members. This is used when reinitializing a member in a backing store.
Bug: chromium:1056170
Change-Id: I410766a9c9133a1f1c2ea2e1153cb1c61363459f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859944
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74341}
Fix crash on Mac64 Debug build. The reason of the failure: misaligned
stack. Fix: apply attribute to force the stack be realigned.
Original description:
> The previous attempt has broken the tsan bot. The only reliable way to
> make sure that registers are not clobbered is by doing direct call from
> inline assembly, which is what this CL does.
> Change-Id: I6adbd5e735949a7cc4cc7fc686ee8c428863ffb9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859947
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74313}
Change-Id: I842d6876c2cf287cfe74e53e7cb45028dff61a56
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2865748
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74336}
The marking verifier used to run on a different stack than the marker
which could lead to it finding more objects than the marker. Fix this
by recording a stack end from which the verification starts. This
ensures that the verifier only finds a subset of the objects that the
actual stack scan finds.
Bug: v8:11709
Change-Id: I44fe7b247e56e75deded45b64c25379f1ad9e381
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859848
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74320}
This reverts commit c4cb14c754.
Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20-%20debug/33969
Original change's description:
> cppgc: Try to fix test IteratePointersFindsCalleeSavedRegisters, vol.2
>
> The previous attempt has broken the tsan bot. The only reliable way to
> make sure that registers are not clobbered is by doing direct call from
> inline assembly, which is what this CL does.
>
> Change-Id: I6adbd5e735949a7cc4cc7fc686ee8c428863ffb9
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859947
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74313}
Change-Id: I00260aeacdac8704475b37fd99d4ef552c523249
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2865746
Auto-Submit: Michael Achenbach <machenbach@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/master@{#74314}
The previous attempt has broken the tsan bot. The only reliable way to
make sure that registers are not clobbered is by doing direct call from
inline assembly, which is what this CL does.
Change-Id: I6adbd5e735949a7cc4cc7fc686ee8c428863ffb9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859947
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74313}
cpplint rules change over time, and we change the exact rules we enable
for v8. This CL removes NOLINT annotations which are not needed
according to the currently enabled rules.
R=ahaas@chromium.org
Bug: v8:11717
Change-Id: Ica92f4ddc9c351c1c63147cbcf050086ca26cc07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859854
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74297}
This reverts commit 4ff37d3a3f.
Reason for revert: Fails with stress_incremental_marking - https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20stress-incremental-marking/3049/blamelist
Original change's description:
> cppgc: Fix test IteratePointersFindsCalleeSavedRegisters
>
> call the compiler can clobber the tested register. Moving this tricky
> part into a noninlinable lambda allows to reduce pressure from the
> register allocator and thereby avoid such clobbering.
>
> Subtle: between the first inline assembly and the IteratePointers()
> Change-Id: Ibeca8fa2f4fd54d07c2f585a4e876504a6a991b7
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859843
> Commit-Queue: Anton Bikineev <bikineev@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#74280}
Change-Id: Ib257e30273f382d19ec922e2fa3279c39e918cde
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859847
Auto-Submit: Maya Lekova <mslekova@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/master@{#74282}
call the compiler can clobber the tested register. Moving this tricky
part into a noninlinable lambda allows to reduce pressure from the
register allocator and thereby avoid such clobbering.
Subtle: between the first inline assembly and the IteratePointers()
Change-Id: Ibeca8fa2f4fd54d07c2f585a4e876504a6a991b7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859843
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74280}
