Dynamic Memory Allocation. CS 351: Systems Programming Michael Saelee

Transcription

1 Dynamic Memory Allocation CS 351: Systems Programming Michael Saelee 1

2 from: registers cache (SRAM) main memory (DRAM) local hard disk drive (HDD/SSD) remote storage (networked drive / cloud) The Memory Hierarchy 2

3 we now have: Virtual Memory 3

4 now what? 4

5 - code, global variables, jump tables, etc. - allocated at fork/exec - lifetime: permanent Static Data 5

6 The Stack - function activation records - local vars, arguments, return values - lifetime: LIFO pages allocated as needed (up to preset stack limit) 6

7 explicitly requested from the kernel - for dynamic allocation - lifetime: arbitrary! The Heap 7

8 - starts out empty - brk pointer marks top of the heap brk The Heap 8

9 heap mgmt syscall: void *sbrk(int inc); /* resizes heap by inc, returns old brk value */ The Heap brk 9

10 brk void *hp = sbrk(n); N hp The Heap 10

11 can use sbrk to allocate structures: int **make_jagged_arr(int nrows, const int *dims) { int i, j; int **jarr = sbrk(sizeof(int *) * nrows); for (i=0; i<nrows; i++) jarr[i] = sbrk(sizeof(int) * dims[i]); return jarr; } 11

12 but we can t free this memory!!! int **make_jagged_arr(int nrows, const int *dims) { int i, j; int **jarr = sbrk(sizeof(int *) * nrows); for (i=0; i<nrows; i++) jarr[i] = sbrk(sizeof(int) * dims[i]); return jarr; } void free_jagged_arr(int **jarr, int nrows) { int i; for (i=0; i<nrows; i++) free(jarr[i]); free(jarr); } 12

13 after the kernel allocates heap space for a process, it is up to the process to manage it! 13

14 manage =tracking memory in use, tracking memory not in use, reusing unused memory 14

15 job of the dynamic memory allocator typically included as a user-level library and/or language runtime feature 15

16 application program User Process dynamic memory allocator malloc Heap sbrk OS kernel RAM Disk 16

17 application program User Process dynamic memory allocator free(p) Heap OS kernel RAM Disk 17

18 application program User Process dynamic memory allocator free(p) Heap OS kernel RAM (heap space may not be returned to the kernel!) Disk 18

19 the DMA constructs a user-level abstraction (re-usable blocks of memory) on top of a kernel-level one (virtual memory) 19

20 the user-level implementation must make good use of the underlying infrastructure (the memory hierarchy) 20

21 e.g., the DMA should: - maintain data alignment - maximize throughput of requests - help maximize memory utilization - leverage locality how to quantify this? 21

22 utilization = fraction of memory in use - in use is a relative concept - for DMA, in use = amount of memory actually requested by user (aka payload) - vs. heap space obtained via sbrk 22

23 p1 = malloc(1024); // util = 1K/4K = 25% Heap (given: 4KB page size) 4KB 23

24 p1 = malloc(1024); // util = 1K/4K = 25% p2 = malloc(2048); // util = 3K/4K = 75% Heap (given: 4KB page size) 4KB 24

25 p1 = malloc(1024); // util = 1K/4K = 25% p2 = malloc(2048); // util = 3K/4K = 75% free(p1); // util = 2K/4K = 50% Heap (given: 4KB page size) 4KB 25

26 p1 = malloc(1024); // util = 1K/4K = 25% p2 = malloc(2048); // util = 3K/4K = 75% free(p1); // util = 2K/4K = 50% p3 = malloc(2048); // util = 4K/8K = 50% Heap (given: 4KB page size) 8KB 4KB 26

27 p1 = malloc(1024); // util = 1K/4K = 25% p2 = malloc(2048); // util = 3K/4K = 75% free(p1); // util = 2K/4K = 50% p3 = malloc(2048); // util = 4K/8K = 50% free(p3); // util = 2K/8K = 25% free(p2); // util = 0/8K = 0% // all non- leaking // programs end in 0% Heap (given: 4KB page size) 8KB 27

28 makes no sense to measure utilization at the end of process execution, and it makes no sense to arbitrarily measure utilization during execution 28

29 instead, measure peak memory utilization - ratio between maximum aggregate payload and maximum heap size - high water mark measure - assuming the heap never shrinks, end heap size = max heap size 29

30 p1 = malloc(1024); // util = 1K/4K = 25% p2 = malloc(2048); // util = 3K/4K = 75% free(p1); // util = 2K/4K = 50% p3 = malloc(2048); // util = 4K/8K = 50% free(p3); // util = 2K/8K = 25% free(p2); // util = 0/8K = 0% - max agg. payload = 4K - max heap size = 8K - peak memory util = 50% // all non- leaking // programs end in 0% 30

31 aggregate payload p1 = malloc(100); p2 = malloc(200); free(p1); p3 = malloc(300); free(p2); p4 = malloc(100); p5 = malloc(200); free(p3); p6 = malloc(100); p7 = malloc(300); free(p4); free(p5); p8 = malloc(200); // 100 // 300 // 200 // 500 // 300 // 400 // 600 // 300 // 400 // 700 // 600 // 400 // 600 peak memory util = 700 / % // measured heap size // at end is 1K 31

32 utilization is affected by memory fragmentation two forms: 1. internal fragmentation 2. external fragmentation 32

33 when allocating blocks of memory, it is convenient to make them self-describing i.e., store metadata alongside blocks with size, allocation status, etc. 33

34 allocator must also adhere to alignment requirements (to help optimize cache/ memory fetches) 34

35 metadata block payload internal fragmentation padding (for alignment) 35

36 amount of internal fragmentation is easy to predict, as it s based on pre-determined factors - metadata = fixed amount - k-byte alignment max k 1 padding 36

37 Heap 37

38 Heap 38

39 Heap external fragmentation 39

40 Heap external fragmentation may affect future heap utilization; i.e., by preventing free space from being re-used 40

41 Heap malloc? 41

42 Heap 42

43 Heap forced to request more heap space malloc? 43

44 hard to predict the effect of external fragmentation on utilization in general, we might: - prefer fewer, larger spans of free space - try to keep similarly sized blocks together in memory 44

45 but these recommendations are heuristics! - may be defeated by pathological cases - don t account for real-world behavior 45

46 It has been proven that for any possible allocation algorithm, there will always be the possibility that some application program will allocate and deallocate blocks in some fashion that defeats the allocator s strategy and forces it into severe fragmentation... Not only are there no provably good allocation algorithms, there are proofs that any allocator will be bad for some possible applications. P. Wilson, M. Johnstone, M. Neely, D. Boles, Dynamic Memory Allocation: A Survey and Critical Review 46