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/platform/wtf/allocator/Allocator.md

Issue 2870213002: Update the PartitionAlloc documentation. (Closed)
Patch Set: Respond to comments. Created 3 years, 7 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 # Design Of PartitionAlloc In Blink
2
3 All objects in Blink are expected to be allocated with PartitionAlloc or Oilpan.
4
5 Blink uses different PartitionAlloc partitions, for different kinds of objects:
6
7 * LayoutObject partition: A partition to allocate `LayoutObject`s.
8 The LayoutObject partition is a `SizeSpecificPartitionAllocator`. This means
9 that no extra padding is needed to allocate a `LayoutObject` object. Different
10 sizes of `LayoutObject`s are allocated in different buckets. Having a dedicated
11 partition for `LayoutObject`s improves cache locality and thus performance.
12
13 * Buffer partition: A partition to allocate objects that have a strong risk
14 that the length and/or the contents are exploited by user scripts. Specifically,
15 we allocate `Vector`s, `HashTable`s, and `String`s in the Buffer partition.
16
17 * ArrayBuffer partition: A partition to allocate `ArrayBufferContents`s.
18
19 * FastMalloc partition: A partition to allocate all other objects. Objects
20 marked with `USING_FAST_MALLOC` are allocated on the FastMalloc partition.
21
22 The Buffer partition and the FastMalloc partition have many buckets. They
23 support any arbitrary size of allocations but padding may be added to align the
24 allocation with the closest bucket size. The bucket sizes are chosen to keep the
25 worst-case memory overhead less than 10%.
26
27 ## Security
28
29 We put `LayoutObject`s into a dedicated partition because `LayoutObject`s are
30 likely to be a source of use-after-free (UAF) vulnerabilities. Similarly, we put
31 `String`s, `Vector`s, et c. into the Buffer partition, and
32 `ArrayBufferContents`s into the ArrayBuffer partition, because malicious web
33 contents are likely to exploit the length field and/or contents of these
34 objects.
35
36 ## Performance
37
38 PartitionAlloc doesn't acquire a lock when allocating on the LayoutObject
39 partition, because it's guaranteed that `LayoutObject`s are allocated only by
40 the main thread.
41
42 PartitionAlloc acquires a lock when allocating on the Buffer, ArrayBuffer, and
43 FastMalloc partitions.
OLDNEW
« no previous file with comments | « base/allocator/partition_allocator/partition_alloc.h ('k') | third_party/WebKit/Source/platform/wtf/allocator/Partitions.h » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698