Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(93)

Side by Side Diff: third_party/WebKit/Source/wtf/Allocator.md

Issue 2767153004: Move files in wtf/ to platform/wtf/ (Part 12). (Closed)
Patch Set: Rebase. Created 3 years, 9 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
OLDNEW
(Empty)
1 # Memory management in Blink
2
3 This document gives a high-level overview of the memory management in Blink.
4
5 [TOC]
6
7 ## Memory allocators
8
9 Blink objects are allocated by one of the following four memory allocators.
10
11 ### Oilpan
12
13 Oilpan is a garbage collection system in Blink.
14 The lifetime of objects allocated by Oilpan is automatically managed.
15 The following objects are allocated by Oilpan:
16
17 * Objects that inherit from GarbageCollected<T> or GarbageCollectedFinalized<T>.
18
19 * HeapVector<T>, HeapHashSet<T>, HeapHashMap<T, U> etc
20
21 The implementation is in platform/heap/.
22 See [BlinkGCDesign.md](../platform/heap/BlinkGCDesign.md) to learn the design.
23
24 ### PartitionAlloc
25
26 PartitionAlloc is Blink's default memory allocator.
27 PartitionAlloc is highly optimized for performance and security requirements
28 in Blink. All Blink objects that don't need a GC or discardable memory should be
29 allocated by PartitionAlloc (instead of malloc).
30 The following objects are allocated by PartitionAlloc:
31
32 * Objects that have a USING_FAST_MALLOC macro.
33
34 * Nodes (which will be moved to Oilpan in the near future)
35
36 * LayoutObjects
37
38 * Strings, Vectors, HashTables, ArrayBuffers and other primitive containers.
39
40 The implementation is in /base/allocator/partition_allocator.
41 See [PartitionAlloc.md](/base/allocator/partition_allocator/PartitionAlloc.md)
42 to learn the design.
43
44 ### Discardable memory
45
46 Discardable memory is a memory allocator that automatically discards
47 (not-locked) objects under memory pressure. Currently SharedBuffers
48 (which are mainly used as backing storage of Resource objects) are the only
49 user of the discardable memory.
50
51 The implementation is in src/base/memory/discardable_memory.*.
52 See [this document](https://docs.google.com/document/d/1aNdOF_72_eG2KUM_z9kHdbT_ fEupWhaDALaZs5D8IAg/edit)
53 to learn the design.
54
55 ### malloc
56
57 When you simply call 'new' or 'malloc', the object is allocated by malloc.
58 As mentioned above, malloc is discouraged and should be replaced with
59 PartitionAlloc. PartitionAlloc is faster, securer and more instrumentable
60 than malloc.
61
62 The actual implementation of malloc is platform-dependent.
63 As of 2015 Dec, Linux uses tcmalloc. Mac and Windows use their system allocator.
64 Android uses device-dependent allocators such as dlmalloc.
65
66 ## Basic allocation rules
67
68 In summary, Blink objects (except several special objects) should be allocated
69 using Oilpan or PartitionAlloc. malloc is discouraged.
70
71 The following is a basic rule to determine which of Oilpan or PartitionAlloc
72 you should use when allocating a new object:
73
74 * Use Oilpan if you want a GC to manage the lifetime of the object.
75 You need to make the object inherit from GarbageCollected<T> or
76 GarbageCollectedFinalized<T>. See
77 [BlinkGCAPIReference.md](../platform/heap/BlinkGCAPIReference.md) to learn
78 programming with Oilpan.
79
80 ```c++
81 class X : public GarbageCollected<X> {
82 ...;
83 };
84
85 void func() {
86 X* x = new X; // This is allocated by Oilpan.
87 }
88 ```
89
90 * Use PartitionAlloc if you don't need a GC to manage the lifetime of
91 the object (i.e., if RefPtr or OwnPtr is enough to manage the lifetime
92 of the object). You need to add a USING_FAST_MALLOC macro to the object.
93
94 ```c++
95 class X {
96 USING_FAST_MALLOC(X);
97 ...;
98 };
99
100 void func() {
101 RefPtr<X> x = adoptRefPtr(new X); // This is allocated by PartitionAlloc.
102 }
103 ```
104
105 It is not a good idea to unnecessarily increase the number of objects
106 managed by Oilpan. Although Oilpan implements an efficient GC, the more objects
107 you allocate on Oilpan, the more pressure you put on Oilpan, leading to
108 a longer pause time.
109
110 Here is a guideline for when you ought to allocate an object using Oilpan,
111 and when you probably shouldn't:
112
113 * Use Oilpan for all script exposed objects (i.e., derives from
114 ScriptWrappable).
115
116 * Use Oilpan if managing its lifetime is usually simpler with Oilpan.
117 But see the next bullet.
118
119 * If the allocation rate of the object is very high, that may put unnecessary
120 strain on the Oilpan's GC infrastructure as a whole. If so and the object can be
121 allocated not using Oilpan without creating cyclic references or complex
122 lifetime handling, then use PartitionAlloc. For example, we allocate Strings
123 and LayoutObjects on PartitionAlloc.
124
125 For objects that don't need an operator new, you need to use either of the
126 following macros:
127
128 * If the object is only stack allocated, use STACK_ALLOCATED().
129
130 ```c++
131 class X {
132 STACK_ALLOCATED();
133 ...;
134 };
135
136 void func() {
137 X x; // This is allowed.
138 X* x2 = new X; // This is forbidden.
139 }
140 ```
141
142 * If the object can be allocated only as a part of object, use DISALLOW_NEW().
143
144 ```c++
145 class X {
146 DISALLOW_NEW();
147 ...;
148 };
149
150 class Y {
151 USING_FAST_MALLOC(Y);
152 X m_x; // This is allowed.
153 };
154
155 void func() {
156 X x; // This is allowed.
157 X* x = new X; // This is forbidden.
158 }
159 ```
160
161 * If the object can be allocated only as a part of object or by a placement new
162 (e.g., the object is used as a value object in a container),
163 use DISALLOW_NEW_EXCEPT_PLACEMENT_NEW().
164
165 ```c++
166 class X {
167 DISALLOW_NEW_EXCEPT_PLACEMENT_NEW();
168 ...;
169 };
170
171 class Y {
172 USING_FAST_MALLOC(Y);
173 X m_x; // This is allowed.
174 Vector<X> m_vector; // This is allowed.
175 };
176
177 void func() {
178 X x; // This is allowed.
179 X* x = new X; // This is forbidden.
180 }
181 ```
182
183 Note that these macros are inherited. See a comment in wtf/Allocator.h
184 for more details about the relationship between the macros and Oilpan.
185
186 If you have any question, ask oilpan-reviews@chromium.org.
OLDNEW
« no previous file with comments | « third_party/WebKit/Source/platform/wtf/debug/DEPS ('k') | third_party/WebKit/Source/wtf/BUILD.gn » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698