ソースを参照

Update 'PLAN.md'

Cameron Weinfurt 5ヶ月前
コミット
ab87ce8a43
1個のファイルの変更15行の追加10行の削除
  1. 15
    10
      PLAN.md

+ 15
- 10
PLAN.md ファイルの表示

@@ -1,14 +1,19 @@
1
-## Problem:
2
-	Memory allocations can be classified into two groups: single allocation with resizing, and frequent static size allocation/deallocation. The first is usually seen with vectors while the second is often seen with linked lists and trees. The problem is to create a memory allocation system that attempts to support both of these types of allocations effeciently while also allowing for multi-granularity allocations.
1
+# Problem:
2
+	
3
+Memory allocations can be classified into two groups: single allocation with resizing, and frequent static size allocation/deallocation. The first is usually seen with vectors while the second is often seen with linked lists and trees. The problem is to create a memory allocation system that attempts to support both of these types of allocations effeciently while also allowing for multi-granularity allocations.
3 4
 
4
-## Proposed Solution:
5
-	Instead of trying to optimze both allocation schemes at once, it may be more effective to have two allocators that specialize for each type of allocation. In addition, granularity can be handled by allowing for recursive allocators of increasing granularity. As this recursion can be modeled using a tree, the tree allocator will be used for allocation sub-allocators.
5
+# Proposed Solution:
6
+	
7
+Instead of trying to optimze both allocation schemes at once, it may be more effective to have two allocators that specialize for each type of allocation. In addition, granularity can be handled by allowing for recursive allocators of increasing granularity. As this recursion can be modeled using a tree, the tree allocator will be used for allocation sub-allocators.
6 8
 
7
-# Allocator 1: Watermark allocator
8
-	This allocator has a very small footprint and amount of time spent on overhead at the cost of being wasteful with space. If kept small, however, the ability to cheaply allocate seems optimal for frequent static allocations.
9
+## Allocator 1: Watermark allocator
9 10
 
10
-# Allocator 2: Tree allocator
11
-	In constrast to the watermark allocator, this allocator has a larger footprint and takes more time for overhead in exchange for smarter allocation and the ability to resize. By organizing allocations and free space in a binary search tree based on the size of the space, the allocations are evenly spaced across the allocatable region. This approach aims to maximize the ability for allocations to be resized in place without requiring a move. 
11
+This allocator has a very small footprint and amount of time spent on overhead at the cost of being wasteful with space. If kept small, however, the ability to cheaply allocate seems optimal for frequent static allocations.
12 12
 
13
-	Idea: Rather than always moving the block that is trying to be resized, move the smaller of the two. The exception being that allocators can't be moved. 
14
-	Note: As this needs to support sub-allocators, it needs to keep track of which are allocators. However, this means that allocations can be done at the top and then trickle down until it finds a space to allocate while creating any new allocators it needs.
13
+## Allocator 2: Tree allocator
14
+	
15
+In constrast to the watermark allocator, this allocator has a larger footprint and takes more time for overhead in exchange for smarter allocation and the ability to resize. By organizing allocations and free space in a binary search tree based on the size of the space, the allocations are evenly spaced across the allocatable region. This approach aims to maximize the ability for allocations to be resized in place without requiring a move. 
16
+
17
+Idea: Rather than always moving the block that is trying to be resized, move the smaller of the two. The exception being that allocators can't be moved. 
18
+
19
+Note: As this needs to support sub-allocators, it needs to keep track of which are allocators. However, this means that allocations can be done at the top and then trickle down until it finds a space to allocate while creating any new allocators it needs.

読み込み中…
キャンセル
保存