Skip to content

Commit 517b81b

Browse files
authored
Upgrade V8 binaries for 10.9.194.10 version
1 parent 7d843f1 commit 517b81b

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

86 files changed

+3927
-1793
lines changed

deps/include/OWNERS

+5-2
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,12 @@ [email protected]
77

88
per-file *DEPS=file:../COMMON_OWNERS
99
per-file v8-internal.h=file:../COMMON_OWNERS
10-
per-file v8-inspector.h=file:../src/inspector/OWNERS
11-
per-file v8-inspector-protocol.h=file:../src/inspector/OWNERS
10+
11+
per-file v8-debug.h=file:../src/debug/OWNERS
12+
1213
per-file js_protocol.pdl=file:../src/inspector/OWNERS
14+
per-file v8-inspector*=file:../src/inspector/OWNERS
15+
per-file v8-inspector*=file:../src/inspector/OWNERS
1316

1417
# Needed by the auto_tag builder
1518
per-file v8-version.h=v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com

deps/include/cppgc/README.md

+121-2
Original file line numberDiff line numberDiff line change
@@ -1,16 +1,135 @@
11
# Oilpan: C++ Garbage Collection
22

33
Oilpan is an open-source garbage collection library for C++ that can be used stand-alone or in collaboration with V8's JavaScript garbage collector.
4+
Oilpan implements mark-and-sweep garbage collection (GC) with limited compaction (for a subset of objects).
45

56
**Key properties**
7+
68
- Trace-based garbage collection;
9+
- Incremental and concurrent marking;
10+
- Incremental and concurrent sweeping;
711
- Precise on-heap memory layout;
812
- Conservative on-stack memory layout;
913
- Allows for collection with and without considering stack;
10-
- Incremental and concurrent marking;
11-
- Incremental and concurrent sweeping;
1214
- Non-incremental and non-concurrent compaction for selected spaces;
1315

1416
See the [Hello World](https://chromium.googlesource.com/v8/v8/+/main/samples/cppgc/hello-world.cc) example on how to get started using Oilpan to manage C++ code.
1517

1618
Oilpan follows V8's project organization, see e.g. on how we accept [contributions](https://v8.dev/docs/contribute) and [provide a stable API](https://v8.dev/docs/api).
19+
20+
## Threading model
21+
22+
Oilpan features thread-local garbage collection and assumes heaps are not shared among threads.
23+
In other words, objects are accessed and ultimately reclaimed by the garbage collector on the same thread that allocates them.
24+
This allows Oilpan to run garbage collection in parallel with mutators running in other threads.
25+
26+
References to objects belonging to another thread's heap are modeled using cross-thread roots.
27+
This is even true for on-heap to on-heap references.
28+
29+
Oilpan heaps may generally not be accessed from different threads unless otherwise noted.
30+
31+
## Heap partitioning
32+
33+
Oilpan's heaps are partitioned into spaces.
34+
The space for an object is chosen depending on a number of criteria, e.g.:
35+
36+
- Objects over 64KiB are allocated in a large object space
37+
- Objects can be assigned to a dedicated custom space.
38+
Custom spaces can also be marked as compactable.
39+
- Other objects are allocated in one of the normal page spaces bucketed depending on their size.
40+
41+
## Precise and conservative garbage collection
42+
43+
Oilpan supports two kinds of GCs:
44+
45+
1. **Conservative GC.**
46+
A GC is called conservative when it is executed while the regular native stack is not empty.
47+
In this case, the native stack might contain references to objects in Oilpan's heap, which should be kept alive.
48+
The GC scans the native stack and treats the pointers discovered via the native stack as part of the root set.
49+
This kind of GC is considered imprecise because values on stack other than references may accidentally appear as references to on-heap object, which means these objects will be kept alive despite being in practice unreachable from the application as an actual reference.
50+
51+
2. **Precise GC.**
52+
A precise GC is triggered at the end of an event loop, which is controlled by an embedder via a platform.
53+
At this point, it is guaranteed that there are no on-stack references pointing to Oilpan's heap.
54+
This means there is no risk of confusing other value types with references.
55+
Oilpan has precise knowledge of on-heap object layouts, and so it knows exactly where pointers lie in memory.
56+
Oilpan can just start marking from the regular root set and collect all garbage precisely.
57+
58+
## Atomic, incremental and concurrent garbage collection
59+
60+
Oilpan has three modes of operation:
61+
62+
1. **Atomic GC.**
63+
The entire GC cycle, including all its phases (e.g. see [Marking](#Marking-phase) and [Sweeping](#Sweeping-phase)), are executed back to back in a single pause.
64+
This mode of operation is also known as Stop-The-World (STW) garbage collection.
65+
It results in the most jank (due to a single long pause), but is overall the most efficient (e.g. no need for write barriers).
66+
67+
2. **Incremental GC.**
68+
Garbage collection work is split up into multiple steps which are interleaved with the mutator, i.e. user code chunked into tasks.
69+
Each step is a small chunk of work that is executed either as dedicated tasks between mutator tasks or, as needed, during mutator tasks.
70+
Using incremental GC introduces the need for write barriers that record changes to the object graph so that a consistent state is observed and no objects are accidentally considered dead and reclaimed.
71+
The incremental steps are followed by a smaller atomic pause to finalize garbage collection.
72+
The smaller pause times, due to smaller chunks of work, helps with reducing jank.
73+
74+
3. **Concurrent GC.**
75+
This is the most common type of GC.
76+
It builds on top of incremental GC and offloads much of the garbage collection work away from the mutator thread and on to background threads.
77+
Using concurrent GC allows the mutator thread to spend less time on GC and more on the actual mutator.
78+
79+
## Marking phase
80+
81+
The marking phase consists of the following steps:
82+
83+
1. Mark all objects in the root set.
84+
85+
2. Mark all objects transitively reachable from the root set by calling `Trace()` methods defined on each object.
86+
87+
3. Clear out all weak handles to unreachable objects and run weak callbacks.
88+
89+
The marking phase can be executed atomically in a stop-the-world manner, in which all 3 steps are executed one after the other.
90+
91+
Alternatively, it can also be executed incrementally/concurrently.
92+
With incremental/concurrent marking, step 1 is executed in a short pause after which the mutator regains control.
93+
Step 2 is repeatedly executed in an interleaved manner with the mutator.
94+
When the GC is ready to finalize, i.e. step 2 is (almost) finished, another short pause is triggered in which step 2 is finished and step 3 is performed.
95+
96+
To prevent a user-after-free (UAF) issues it is required for Oilpan to know about all edges in the object graph.
97+
This means that all pointers except on-stack pointers must be wrapped with Oilpan's handles (i.e., Persistent<>, Member<>, WeakMember<>).
98+
Raw pointers to on-heap objects create an edge that Oilpan cannot observe and cause UAF issues
99+
Thus, raw pointers shall not be used to reference on-heap objects (except for raw pointers on native stacks).
100+
101+
## Sweeping phase
102+
103+
The sweeping phase consists of the following steps:
104+
105+
1. Invoke pre-finalizers.
106+
At this point, no destructors have been invoked and no memory has been reclaimed.
107+
Pre-finalizers are allowed to access any other on-heap objects, even those that may get destructed.
108+
109+
2. Sweeping invokes destructors of the dead (unreachable) objects and reclaims memory to be reused by future allocations.
110+
111+
Assumptions should not be made about the order and the timing of their execution.
112+
There is no guarantee on the order in which the destructors are invoked.
113+
That's why destructors must not access any other on-heap objects (which might have already been destructed).
114+
If some destructor unavoidably needs to access other on-heap objects, it will have to be converted to a pre-finalizer.
115+
The pre-finalizer is allowed to access other on-heap objects.
116+
117+
The mutator is resumed before all destructors have ran.
118+
For example, imagine a case where X is a client of Y, and Y holds a list of clients.
119+
If the code relies on X's destructor removing X from the list, there is a risk that Y iterates the list and calls some method of X which may touch other on-heap objects.
120+
This causes a use-after-free.
121+
Care must be taken to make sure that X is explicitly removed from the list before the mutator resumes its execution in a way that doesn't rely on X's destructor (e.g. a pre-finalizer).
122+
123+
Similar to marking, sweeping can be executed in either an atomic stop-the-world manner or incrementally/concurrently.
124+
With incremental/concurrent sweeping, step 2 is interleaved with mutator.
125+
Incremental/concurrent sweeping can be atomically finalized in case it is needed to trigger another GC cycle.
126+
Even with concurrent sweeping, destructors are guaranteed to run on the thread the object has been allocated on to preserve C++ semantics.
127+
128+
Notes:
129+
130+
* Weak processing runs only when the holder object of the WeakMember outlives the pointed object.
131+
If the holder object and the pointed object die at the same time, weak processing doesn't run.
132+
It is wrong to write code assuming that the weak processing always runs.
133+
134+
* Pre-finalizers are heavy because the thread needs to scan all pre-finalizers at each sweeping phase to determine which pre-finalizers should be invoked (the thread needs to invoke pre-finalizers of dead objects).
135+
Adding pre-finalizers to frequently created objects should be avoided.

deps/include/cppgc/common.h

-1
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,6 @@
55
#ifndef INCLUDE_CPPGC_COMMON_H_
66
#define INCLUDE_CPPGC_COMMON_H_
77

8-
// TODO(chromium:1056170): Remove dependency on v8.
98
#include "v8config.h" // NOLINT(build/include_directory)
109

1110
namespace cppgc {

deps/include/cppgc/cross-thread-persistent.h

+7-8
Original file line numberDiff line numberDiff line change
@@ -120,7 +120,7 @@ class BasicCrossThreadPersistent final : public CrossThreadPersistentBase,
120120
if (!IsValid(raw)) return;
121121
PersistentRegionLock guard;
122122
CrossThreadPersistentRegion& region = this->GetPersistentRegion(raw);
123-
SetNode(region.AllocateNode(this, &Trace));
123+
SetNode(region.AllocateNode(this, &TraceAsRoot));
124124
this->CheckPointer(raw);
125125
}
126126

@@ -138,7 +138,7 @@ class BasicCrossThreadPersistent final : public CrossThreadPersistentBase,
138138
: CrossThreadPersistentBase(raw), LocationPolicy(loc) {
139139
if (!IsValid(raw)) return;
140140
CrossThreadPersistentRegion& region = this->GetPersistentRegion(raw);
141-
SetNode(region.AllocateNode(this, &Trace));
141+
SetNode(region.AllocateNode(this, &TraceAsRoot));
142142
this->CheckPointer(raw);
143143
}
144144

@@ -349,9 +349,8 @@ class BasicCrossThreadPersistent final : public CrossThreadPersistentBase,
349349
return ptr && ptr != kSentinelPointer;
350350
}
351351

352-
static void Trace(Visitor* v, const void* ptr) {
353-
const auto* handle = static_cast<const BasicCrossThreadPersistent*>(ptr);
354-
v->TraceRoot(*handle, handle->Location());
352+
static void TraceAsRoot(RootVisitor& root_visitor, const void* ptr) {
353+
root_visitor.Trace(*static_cast<const BasicCrossThreadPersistent*>(ptr));
355354
}
356355

357356
void AssignUnsafe(T* ptr) {
@@ -378,7 +377,7 @@ class BasicCrossThreadPersistent final : public CrossThreadPersistentBase,
378377
SetValue(ptr);
379378
if (!IsValid(ptr)) return;
380379
PersistentRegionLock guard;
381-
SetNode(this->GetPersistentRegion(ptr).AllocateNode(this, &Trace));
380+
SetNode(this->GetPersistentRegion(ptr).AllocateNode(this, &TraceAsRoot));
382381
this->CheckPointer(ptr);
383382
}
384383

@@ -398,7 +397,7 @@ class BasicCrossThreadPersistent final : public CrossThreadPersistentBase,
398397
}
399398
SetValue(ptr);
400399
if (!IsValid(ptr)) return;
401-
SetNode(this->GetPersistentRegion(ptr).AllocateNode(this, &Trace));
400+
SetNode(this->GetPersistentRegion(ptr).AllocateNode(this, &TraceAsRoot));
402401
this->CheckPointer(ptr);
403402
}
404403

@@ -416,7 +415,7 @@ class BasicCrossThreadPersistent final : public CrossThreadPersistentBase,
416415
return static_cast<T*>(const_cast<void*>(GetValueFromGC()));
417416
}
418417

419-
friend class cppgc::Visitor;
418+
friend class internal::RootVisitor;
420419
};
421420

422421
template <typename T, typename LocationPolicy, typename CheckingPolicy>

deps/include/cppgc/default-platform.h

+2-10
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,6 @@
66
#define INCLUDE_CPPGC_DEFAULT_PLATFORM_H_
77

88
#include <memory>
9-
#include <vector>
109

1110
#include "cppgc/platform.h"
1211
#include "libplatform/libplatform.h"
@@ -20,15 +19,6 @@ namespace cppgc {
2019
*/
2120
class V8_EXPORT DefaultPlatform : public Platform {
2221
public:
23-
/**
24-
* Use this method instead of 'cppgc::InitializeProcess' when using
25-
* 'cppgc::DefaultPlatform'. 'cppgc::DefaultPlatform::InitializeProcess'
26-
* will initialize cppgc and v8 if needed (for non-standalone builds).
27-
*
28-
* \param platform DefaultPlatform instance used to initialize cppgc/v8.
29-
*/
30-
static void InitializeProcess(DefaultPlatform* platform);
31-
3222
using IdleTaskSupport = v8::platform::IdleTaskSupport;
3323
explicit DefaultPlatform(
3424
int thread_pool_size = 0,
@@ -64,6 +54,8 @@ class V8_EXPORT DefaultPlatform : public Platform {
6454
return v8_platform_->GetTracingController();
6555
}
6656

57+
v8::Platform* GetV8Platform() const { return v8_platform_.get(); }
58+
6759
protected:
6860
static constexpr v8::Isolate* kNoIsolate = nullptr;
6961

deps/include/cppgc/explicit-management.h

+22-4
Original file line numberDiff line numberDiff line change
@@ -15,11 +15,27 @@ namespace cppgc {
1515

1616
class HeapHandle;
1717

18+
namespace subtle {
19+
20+
template <typename T>
21+
void FreeUnreferencedObject(HeapHandle& heap_handle, T& object);
22+
template <typename T>
23+
bool Resize(T& object, AdditionalBytes additional_bytes);
24+
25+
} // namespace subtle
26+
1827
namespace internal {
1928

20-
V8_EXPORT void FreeUnreferencedObject(HeapHandle&, void*);
21-
V8_EXPORT bool Resize(void*, size_t);
29+
class ExplicitManagementImpl final {
30+
private:
31+
V8_EXPORT static void FreeUnreferencedObject(HeapHandle&, void*);
32+
V8_EXPORT static bool Resize(void*, size_t);
2233

34+
template <typename T>
35+
friend void subtle::FreeUnreferencedObject(HeapHandle&, T&);
36+
template <typename T>
37+
friend bool subtle::Resize(T&, AdditionalBytes);
38+
};
2339
} // namespace internal
2440

2541
namespace subtle {
@@ -45,7 +61,8 @@ template <typename T>
4561
void FreeUnreferencedObject(HeapHandle& heap_handle, T& object) {
4662
static_assert(IsGarbageCollectedTypeV<T>,
4763
"Object must be of type GarbageCollected.");
48-
internal::FreeUnreferencedObject(heap_handle, &object);
64+
internal::ExplicitManagementImpl::FreeUnreferencedObject(heap_handle,
65+
&object);
4966
}
5067

5168
/**
@@ -73,7 +90,8 @@ template <typename T>
7390
bool Resize(T& object, AdditionalBytes additional_bytes) {
7491
static_assert(IsGarbageCollectedTypeV<T>,
7592
"Object must be of type GarbageCollected.");
76-
return internal::Resize(&object, sizeof(T) + additional_bytes.value);
93+
return internal::ExplicitManagementImpl::Resize(
94+
&object, sizeof(T) + additional_bytes.value);
7795
}
7896

7997
} // namespace subtle

deps/include/cppgc/garbage-collected.h

+15-26
Original file line numberDiff line numberDiff line change
@@ -5,8 +5,6 @@
55
#ifndef INCLUDE_CPPGC_GARBAGE_COLLECTED_H_
66
#define INCLUDE_CPPGC_GARBAGE_COLLECTED_H_
77

8-
#include <type_traits>
9-
108
#include "cppgc/internal/api-constants.h"
119
#include "cppgc/platform.h"
1210
#include "cppgc/trace-trait.h"
@@ -16,28 +14,6 @@ namespace cppgc {
1614

1715
class Visitor;
1816

19-
namespace internal {
20-
21-
class GarbageCollectedBase {
22-
public:
23-
// Must use MakeGarbageCollected.
24-
void* operator new(size_t) = delete;
25-
void* operator new[](size_t) = delete;
26-
// The garbage collector is taking care of reclaiming the object. Also,
27-
// virtual destructor requires an unambiguous, accessible 'operator delete'.
28-
void operator delete(void*) {
29-
#ifdef V8_ENABLE_CHECKS
30-
internal::Abort();
31-
#endif // V8_ENABLE_CHECKS
32-
}
33-
void operator delete[](void*) = delete;
34-
35-
protected:
36-
GarbageCollectedBase() = default;
37-
};
38-
39-
} // namespace internal
40-
4117
/**
4218
* Base class for managed objects. Only descendent types of `GarbageCollected`
4319
* can be constructed using `MakeGarbageCollected()`. Must be inherited from as
@@ -74,11 +50,24 @@ class GarbageCollectedBase {
7450
* \endcode
7551
*/
7652
template <typename T>
77-
class GarbageCollected : public internal::GarbageCollectedBase {
53+
class GarbageCollected {
7854
public:
7955
using IsGarbageCollectedTypeMarker = void;
8056
using ParentMostGarbageCollectedType = T;
8157

58+
// Must use MakeGarbageCollected.
59+
void* operator new(size_t) = delete;
60+
void* operator new[](size_t) = delete;
61+
// The garbage collector is taking care of reclaiming the object. Also,
62+
// virtual destructor requires an unambiguous, accessible 'operator delete'.
63+
void operator delete(void*) {
64+
#ifdef V8_ENABLE_CHECKS
65+
internal::Fatal(
66+
"Manually deleting a garbage collected object is not allowed");
67+
#endif // V8_ENABLE_CHECKS
68+
}
69+
void operator delete[](void*) = delete;
70+
8271
protected:
8372
GarbageCollected() = default;
8473
};
@@ -101,7 +90,7 @@ class GarbageCollected : public internal::GarbageCollectedBase {
10190
* };
10291
* \endcode
10392
*/
104-
class GarbageCollectedMixin : public internal::GarbageCollectedBase {
93+
class GarbageCollectedMixin {
10594
public:
10695
using IsGarbageCollectedMixinTypeMarker = void;
10796

0 commit comments

Comments
 (0)