Dynamic Memory Allocation CS 351: Systems Programming Michael - - PowerPoint PPT Presentation

▶

dynamic memory allocation

Dynamic Memory Allocation CS 351: Systems Programming Michael - - PowerPoint PPT Presentation

Nov 20, 2023 315 likes •767 views

Dynamic Memory Allocation CS 351: Systems Programming Michael Saelee <lee@iit.edu> Computer Science Science registers from: cache (SRAM) main memory (DRAM) local hard disk drive (HDD/SSD) remote storage (networked drive / cloud)

slide-1

SLIDE 1

Dynamic Memory Allocation

CS 351: Systems Programming Michael Saelee <lee@iit.edu>

slide-2

SLIDE 2

Computer Science Science

registers cache (SRAM) main memory (DRAM) local hard disk drive (HDD/SSD) remote storage (networked drive / cloud)

from: The Memory Hierarchy

slide-3

SLIDE 3

Computer Science Science

we now have: Virtual Memory

slide-4

SLIDE 4

Computer Science Science

now what?

slide-5

SLIDE 5

Computer Science Science

code, global variables,

jump tables, etc.

allocated at fork/exec
lifetime: permanent

Static Data

slide-6

SLIDE 6

Computer Science Science

pages allocated as needed (up to preset stack limit)

function activation records
local vars, arguments,

return values

lifetime: LIFO

The Stack

slide-7

SLIDE 7

Computer Science Science

for dynamic allocation
lifetime: arbitrary!

The Heap

explicitly requested from the kernel

slide-8

SLIDE 8

Computer Science Science

brk

starts out empty
brk pointer marks top of

the heap

The Heap

slide-9

SLIDE 9

Computer Science Science

void *sbrk(int inc); /* increments brk by inc, returns old brk value */

brk

heap mgmt syscall:

The Heap

slide-10

SLIDE 10

Computer Science Science

hp

void *hp = sbrk(N);

brk

N

The Heap

slide-11

SLIDE 11

Computer Science Science

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

slide-12

SLIDE 12

Computer Science Science

“manage” = tracking memory in use, tracking memory not in use, reusing unused memory

slide-13

SLIDE 13

Computer Science Science

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

slide-14

SLIDE 14

Computer Science Science

User Process

sbrk

Disk RAM

dynamic memory allocator

Heap

OS kernel

malloc

application program

slide-15

SLIDE 15

Computer Science Science

User Process

Disk RAM

dynamic memory allocator

Heap

application program

free(p)

OS kernel

slide-16

SLIDE 16

Computer Science Science

User Process

Disk RAM

dynamic memory allocator

Heap

application program

free(p)

OS kernel

(heap space may not be returned to the kernel!)

slide-17

SLIDE 17

Computer Science Science

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

slide-18

SLIDE 18

Computer Science Science

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

slide-19

SLIDE 19

Computer Science Science

e.g., the DMA should:

maintain data alignment
maximize throughput of requests
help maximize memory utilization
leverage locality

how to quantify this?

slide-20

SLIDE 20

Computer Science Science

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

slide-21

SLIDE 21

Computer Science Science

p1 = malloc(1024); // util = 1K/4K = 25%

Heap

4KB

(given: DMA requests memory in 4KB chunks)

slide-22

SLIDE 22

Computer Science Science

p1 = malloc(1024); // util = 1K/4K = 25% p2 = malloc(2048); // util = 3K/4K = 75%

4KB

Heap

(given: DMA requests memory in 4KB chunks)

slide-23

SLIDE 23

Computer Science Science

p1 = malloc(1024); // util = 1K/4K = 25% p2 = malloc(2048); // util = 3K/4K = 75% free(p1); // util = 2K/4K = 50%

4KB

Heap

(given: DMA requests memory in 4KB chunks)

slide-24

SLIDE 24

Computer Science Science

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%

8KB 4KB

Heap

(given: DMA requests memory in 4KB chunks)

slide-25

SLIDE 25

Computer Science Science

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%

8KB

Heap

(given: DMA requests memory in 4KB chunks)

slide-26

SLIDE 26

Computer Science Science

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

slide-27

SLIDE 27

Computer Science Science

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

slide-28

SLIDE 28

Computer Science Science

max agg. payload = 4K
max heap size

= 8K

peak memory util = 50%

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%

slide-29

SLIDE 29

Computer Science Science

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); // measured heap size // at end is 1K // 100 // 300 // 200 // 500 // 300 // 400 // 600 // 300 // 400 // 700 // 600 // 400 // 600

aggregate payload

peak memory util = 700 / 1024 ≈ 68%

slide-30

SLIDE 30

Computer Science Science

utilization is affected by memory fragmentation two forms:

1. internal fragmentation
2. external fragmentation

slide-31

SLIDE 31

Computer Science Science

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

slide-32

SLIDE 32

Computer Science Science

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

slide-33

SLIDE 33

Computer Science Science

payload metadata padding (for alignment)

“block”

internal fragmentation

slide-34

SLIDE 34

Computer Science Science

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

slide-35

SLIDE 35

Computer Science Science

Heap

slide-36

SLIDE 36

Computer Science Science

Heap

slide-37

SLIDE 37

Computer Science Science

Heap

external fragmentation

slide-38

SLIDE 38

Computer Science Science

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

slide-39

SLIDE 39

Computer Science Science

Heap

malloc?

slide-40

SLIDE 40

Computer Science Science

Heap

slide-41

SLIDE 41

Computer Science Science

Heap

malloc?

forced to request more heap space

slide-42

SLIDE 42

Computer Science Science

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

slide-43

SLIDE 43

Computer Science Science

but these recommendations are heuristics!

may be defeated by pathological cases
don’t account for real-world behavior

slide-44

SLIDE 44

Computer Science Science

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