Title: CS 213 Introduction to Computer Systems Thinking Inside the Box
1CS 213Introduction to Computer SystemsThinking
Inside the Box
- Instructor Brian M. Dennis
- bmd_at_cs.northwestern.edu
- Teaching Assistant Bin Lin
- binlin_at_cs.northwestern.edu
2Today's Topics
- Dynamic memory management schemes
- Intro to UNIX I/O
3Malloc Package
- include ltstdlib.hgt
- void malloc(size_t size)
- If successful
- Returns a pointer to a memory block of at least
size bytes, (typically) aligned to 8-byte
boundary. - If size 0, returns NULL
- If unsuccessful returns NULL (0) and sets errno.
- void free(void p)
- Returns the block pointed at by p to pool of
available memory - p must come from a previous call to malloc or
realloc. - void realloc(void p, size_t size)
- Changes size of block p and returns pointer to
new block. - Contents of new block unchanged up to min of old
and new size.
4Assumptions
- Assumptions
- Memory is word addressed (each word can hold a
pointer, probably 4 bytes)
Free word
Allocated block (4 words)
Free block (3 words)
Allocated word
5Constraints
- Applications
- Can issue arbitrary sequence of allocation and
free requests - Free requests must correspond to an allocated
block - Allocators
- Cant control number or size of allocated blocks
- Must respond immediately to all allocation
requests - i.e., cant reorder or buffer requests
- Must allocate blocks from free memory
- i.e., can only place allocated blocks in free
memory - Must align blocks so they satisfy all alignment
requirements - 8 byte alignment for GNU malloc (libc malloc) on
Linux boxes - Can only manipulate and modify free memory
- Cant move the allocated blocks once they are
allocated - i.e., compaction is not allowed
6Goals of Good malloc/free
- Primary goals
- Good time performance for malloc and free
- Ideally should take constant time (not always
possible) - Should certainly not take linear time in the
number of blocks - Good space utilization
- User allocated structures should be large
fraction of the heap. - Want to minimize fragmentation.
- Some other goals
- Good locality properties
- Structures allocated close in time should be
close in space - Similar objects should be allocated close in
space - Robust
- Obeys constraints!!
- Can check that free(p1) is on a valid allocated
object p1 - Can check that memory references are to allocated
space
7Performance Goals Throughput
- Given some sequence of malloc and free requests
- R0, R1, ..., Rk, ... , Rn-1
- Want to maximize throughput and peak memory
utilization. - These goals are often conflicting
- Throughput
- Number of completed requests per unit time
- Example
- 5,000 malloc calls and 5,000 free calls in 10
seconds - Throughput is 1,000 operations/second.
8Performance Goals Peak Memory Utilization
- Given some sequence of malloc and free requests
- R0, R1, ..., Rk, ... , Rn-1
- Def Aggregate payload Pk
- malloc(p) results in a block with a payload of p
bytes.. - After request Rk has completed, the aggregate
payload Pk is the sum of currently allocated
payloads. - Def Current heap size is denoted by Hk
- Assume that Hk is monotonically nondecreasing
- Def Peak memory utilization
- After k requests, peak memory utilization is
- Uk ( maxiltk Pi ) / Hk
9Internal Fragmentation
- Poor memory utilization caused by fragmentation.
- Comes in two forms internal and external
fragmentation - Internal fragmentation
- For some block, internal fragmentation is the
difference between the block size and the payload
size. - Caused by overhead of maintaining heap data
structures, padding for alignment purposes, or
explicit policy decisions (e.g., not to split the
block). - Depends only on the pattern of previous requests,
and thus is easy to measure.
block
Internal fragmentation
payload
Internal fragmentation
10External Fragmentation
p1 malloc(4)
Occurs when there is enough aggregate heap
memory, but no single free block is large enough
p2 malloc(5)
p3 malloc(6)
free(p2)
p4 malloc(7)
oops!
External fragmentation depends on the pattern of
future requests, and thus is difficult to
measure.
11Implementation Issues
- How do we keep track of the free blocks?
- How do we pick a block to use for allocation --
many might fit? - What do we do with the extra space when
allocating a structure that is smaller than the
free block it is placed in? - How do we know how much memory to free just given
a pointer? - How do we reinsert freed block?
p0
free(p0)
p1 malloc(1)
12Knowing How Much to Free
- Standard method (influences rest of decisions)
- Keep the length of a block in the word preceding
the block. - This word is often called the header field or
header - Requires an extra word for every allocated block
p0 malloc(4)
p0
5
free(p0)
Block size
data
13Keeping Track of Free Blocks
- Method 1 Implicit list using lengths -- links
all blocks - Method 2 Explicit list among the free blocks
using pointers within the free blocks - Method 3 Segregated free list
- Different free lists for different size classes
- Method 4 Blocks sorted by size
- Can use a balanced tree (e.g. Red-Black tree)
with pointers within each free block, and the
length used as a key
5
4
2
6
5
4
2
6
14Method 1 Implicit List
- Need to identify whether each block is free or
allocated - Can use extra bit
- Bit can be put in the same word as the size if
block sizes are always multiples of two (mask out
low order bit when reading size).
1 word
a 1 allocated block a 0 free block size
block size payload application data (allocated
blocks only)
size
a
payload
Format of allocated and free blocks
optional padding
15Implicit List Finding a Free Block
- First fit
- Search list from beginning, choose first free
block that fits - Can take linear time in total number of blocks
(allocated and free) - In practice it can cause splinters at beginning
of list - Next fit
- Like first-fit, but search list from location of
end of previous search - Research suggests that fragmentation is worse
- Best fit
- Search the list, choose the free block with the
closest size that fits - Keeps fragments small --- usually helps
fragmentation - Will typically run slower than first-fit
void findblock(size_t len) p start while
((p lt end) \\ not passed end ((p
1) \\ already allocated (p lt
len))) \\ too small addblock(p, len)
16Implicit List Allocating in Free Block
- Allocating in a free block - splitting
- Since allocated space might be smaller than free
space, we might want to split the block
4
4
2
6
p
void addblock(ptr p, int len) int newsize
((len 1) gtgt 1) ltlt 1 // add 1 and round up
int oldsize p (0x1) // mask out low
bit p newsize 1 //
set new length if (newsize lt oldsize)
(pnewsize) oldsize - newsize // set length
in remaining
// part of block
addblock(p, 2)
2
4
2
4
4
17Implicit List Freeing a Block
- Simplest implementation
- Only need to clear allocated flag
- void free_block(ptr p) p p -2
- But can lead to false fragmentation
- There is enough free space, but the allocator
wont be able to find it
2
4
2
4
p
free(p)
2
4
4
2
4
malloc(5)
Oops!
18Implicit List Coalescing
- Join (coelesce) with next and/or previous block
if they are free - Coalescing with next block
-
- But how do we coalesce with previous block, if
need be?
void free_block(ptr p) p p -2
// clear allocated flag next p p
// find next block if ((next 1) 0)
p p next // add to this block if
// not allocated
2
4
2
4
p
free(p)
4
4
2
6
19Implicit List Bidirectional Coalescing
- Boundary tags Knuth73
- Replicate size/allocated word at bottom of free
blocks - Allows us to traverse the list backwards, but
requires extra space - Important and general technique!
1 word
Header
size
a
a 1 allocated block a 0 free block size
total block size payload application
data (allocated blocks only)
payload and padding
Format of allocated and free blocks
size
a
Boundary tag (footer)
4
4
4
4
6
4
6
4
20Constant Time Coalescing
Case 1
Case 2
Case 3
Case 4
allocated
allocated
free
free
block being freed
allocated
free
allocated
free
21Constant Time Coalescing (Case 1)
m1
1
m1
1
m1
1
m1
1
n
1
n
0
n
1
n
0
m2
1
m2
1
m2
1
m2
1
22Constant Time Coalescing (Case 2)
m1
1
m1
1
m1
1
m1
1
nm2
0
n
1
n
1
m2
0
nm2
0
m2
0
23Constant Time Coalescing (Case 3)
m1
0
nm1
0
m1
0
n
1
n
1
nm1
0
m2
1
m2
1
m2
1
m2
1
24Constant Time Coalescing (Case 4)
m1
0
nm1m2
0
m1
0
n
1
n
1
m2
0
m2
0
nm1m2
0
25Keeping Track of Free Blocks
- Method 1 Implicit list using lengths -- links
all blocks - Method 2 Explicit list among the free blocks
using pointers within the free blocks - Method 3 Segregated free list
- Different free lists for different size classes
- Method 4 Blocks sorted by size
- Can use a balanced tree (e.g. Red-Black tree)
with pointers within each free block, and the
length used as a key
5
4
2
6
5
4
2
6
26Explicit Free Lists
- Use data space for link pointers
- Typically doubly linked
- Still need boundary tags for coalescing
- It is important to realize that links are not
necessarily in the same order as the blocks
Forward links
A
B
4
4
4
4
6
6
4
4
4
4
C
Back links
27Allocating From Explicit Free Lists
pred
succ
free block
Before
pred
succ
After (with splitting)
free block
28Freeing With Explicit Free Lists
- Insertion policy Where in the free list do you
put a newly freed block? - LIFO (last-in-first-out) policy
- Insert freed block at the beginning of the free
list - Pro simple and constant time
- Con studies suggest fragmentation is worse than
address ordered. - Address-ordered policy
- Insert freed blocks so that free list blocks are
always in address order - i.e. addr(pred) lt addr(curr) lt addr(succ)
- Con requires search
- Pro studies suggest fragmentation is better
than LIFO
29Freeing With a LIFO Policy
- Case 1 a-a-a
- Insert self at beginning of free list
- Case 2 a-a-f
- Splice out next, coalesce self and next, and add
to beginning of free list
pred (p)
succ (s)
self
a
a
p
s
before
self
a
f
p
s
after
f
a
30Freeing With a LIFO Policy (cont)
p
s
- Case 3 f-a-a
- Splice out prev, coalesce with self, and add to
beginning of free list - Case 4 f-a-f
- Splice out prev and next, coalesce with self, and
add to beginning of list
before
self
f
a
p
s
after
f
a
p1
s1
p2
s2
before
self
f
f
p1
s1
p2
s2
after
f
31Explicit List Summary
- Comparison to implicit list
- Allocate is linear time in number of free blocks
instead of total blocks -- much faster allocates
when most of the memory is full - Slightly more complicated allocate and free since
needs to splice blocks in and out of the list - Some extra space for the links (2 extra words
needed for each block) - Main use of linked lists is in conjunction with
segregated free lists - Keep multiple linked lists of different size
classes, or possibly for different types of
objects
32Keeping Track of Free Blocks
- Method 1 Implicit list using lengths -- links
all blocks - Method 2 Explicit list among the free blocks
using pointers within the free blocks - Method 3 Segregated free list
- Different free lists for different size classes
- Method 4 Blocks sorted by size
- Can use a balanced tree (e.g. Red-Black tree)
with pointers within each free block, and the
length used as a key
5
4
2
6
5
4
2
6
33Segregated Storage
- Each size class has its own collection of blocks
- Often have separate size class for every small
size (2,3,4,) - For larger sizes typically have a size class for
each power of 2
34Simple Segregated Storage
- Separate heap and free list for each size class
- No splitting
- To allocate a block of size n
- If free list for size n is not empty,
- allocate first block on list (note, list can be
implicit or explicit) - If free list is empty,
- get a new page
- create new free list from all blocks in page
- allocate first block on list
- Constant time
- To free a block
- Add to free list
- If page is empty, return the page for use by
another size (optional) - Tradeoffs
- Fast, but can fragment badly
35Segregated Fits
- Array of free lists, each one for some size class
- To allocate a block of size n
- Search appropriate free list for block of size m
gt n - If an appropriate block is found
- Split block and place fragment on appropriate
list (optional) - If no block is found, try next larger class
- Repeat until block is found
- To free a block
- Coalesce and place on appropriate list (optional)
- Tradeoffs
- Faster search than sequential fits (i.e., log
time for power of two size classes) - Controls fragmentation of simple segregated
storage - Coalescing can increase search times
- Deferred coalescing can help
- Popular implementation strategy e.g. GNU malloc
36Keeping Track of Free Blocks
- Method 1 Implicit list using lengths -- links
all blocks - Method 2 Explicit list among the free blocks
using pointers within the free blocks - Method 3 Segregated free list
- Different free lists for different size classes
- Method 4 Blocks sorted by size
- Can use a balanced tree (e.g. Red-Black tree)
with pointers within each free block, and the
length used as a key
5
4
2
6
5
4
2
6
37Summary of Key Allocator Policies
- Placement policy (finding free blocks)
- First fit, next fit, best fit, etc.
- Trades off lower throughput for less
fragmentation - Interesting observation segregated free lists
approximate a best fit placement policy without
having the search entire free list. - Splitting policy (increase utilization, decreases
throughput) - When do we go ahead and split free blocks?
- How much internal fragmentation are we willing to
tolerate? - Coalescing policy (increase utilization,
decreases throughput) - Immediate coalescing coalesce adjacent blocks
each time free is called - Deferred coalescing try to improve performance
of free by deferring coalescing until needed.
e.g., - Coalesce as you scan the free list for malloc.
- Coalesce when the amount of external
fragmentation reaches some threshold.
38Transition to I/O
- Last bit of a process to clean things up
39Unix Files
- A Unix file is a sequence of m bytes
- B0, B1, .... , Bk , .... , Bm-1
- Named using a rooted hierarchy
- All I/O devices are represented as files
- /dev/sda2 (/usr disk partition)
- /dev/tty2 (terminal)
- Even the kernel is exposed as a file
- /dev/kmem (kernel memory image)
- /proc (kernel data structures)
40Unix File Types
- Regular file
- Binary or text file.
- Unix does not know the difference!
- Directory file
- A file that contains the names and locations of
other files. - Character special and block special files
- Terminals (character special) and disks ( block
special) - FIFO (named pipe)
- A file type used for interprocess communication
- Socket
- A file type used for network communication
between processes
41Unix I/O
- The elegant mapping of files to devices allows
kernel to export simple interface called Unix
I/O. - Key Unix idea All input and output is handled in
a consistent and uniform way.
- Low level Unix I/O API (system calls)
- Opening and closing files
- open()and close()
- Changing the current file position (seek)
- lseek()
- Reading and writing a file
- read() and write()
42Opening Files
- Opening a file informs the kernel that you are
getting ready to access that file. - Returns a small identifying integer file
descriptor - fd -1 indicates that an error occurred
- Each process created by a Unix shell begins life
with three open files associated with a terminal - 0 standard input (read only)
- 1 standard output (write only)
- 2 standard error (write only)
int fd / file descriptor / if ((fd
open(/etc/hosts, O_RDONLY)) lt 0)
perror(open) exit(1)
43Closing Files
- Closing a file informs the kernel that you are
finished accessing that file. - Always check return codes, even for seemingly
benign functions such as close()
int fd / file descriptor / int retval /
return value / if ((retval close(fd)) lt 0)
perror(close) exit(1)
44Reading Files
- Reading a file copies bytes from the current file
position to memory, and then updates file
position. - Returns number of bytes read from file fd into
buf - nbytes lt 0 indicates that an error occurred.
- short counts (nbytes lt sizeof(buf) ) are possible
and are not errors!
char buf512 int fd / file descriptor
/ int nbytes / number of bytes read / /
Open file fd ... / / Then read up to 512 bytes
from file fd / if ((nbytes read(fd, buf,
sizeof(buf))) lt 0) perror(read)
exit(1)
45Writing Files
- Writing a file copies bytes from memory to the
current file position, and then updates current
file position. - Returns number of bytes written from buf to file
fd. - nbytes lt 0 indicates that an error occurred.
- As with reads, short counts are possible and are
not errors! - Transfers up to 512 bytes from address buf to
file fd
char buf512 int fd / file descriptor
/ int nbytes / number of bytes read / /
Open the file fd ... / / Then write up to 512
bytes from buf to file fd / if ((nbytes
write(fd, buf, sizeof(buf)) lt 0)
perror(write) exit(1)
46Unix I/O Example
- Copying standard input to standard output one
byte at a time. - Note the use of error handling wrappers for read
and write (Appendix B).
include "csapp.h" int main(void) char
c while(Read(STDIN_FILENO, c, 1) ! 0)
Write(STDOUT_FILENO, c, 1) exit(0)
47Dealing with Short Counts
- Short counts can occur in these situations
- Encountering (end-of-file) EOF on reads.
- Reading text lines from a terminal.
- Reading and writing network sockets or Unix
pipes. - Short counts never occur in these situations
- Reading from disk files (except for EOF)
- Writing to disk files.
- How should you deal with short counts in your
code? - Use the RIO (Robust I/O) package from your
textbooks csapp.c file (Appendix B).
48The RIO Package
- RIO is a set of wrappers that provide efficient
and robust I/O in applications such as network
programs that are subject to short counts. - RIO provides two different kinds of functions
- Unbuffered input and output of binary data
- rio_readn and rio_writen
- Buffered input of binary data and text lines
- rio_readlineb and rio_readnb
- Cleans up some problems with Stevenss readline
and readn functions. - Unlike the Stevens routines, the buffered RIO
routines are thread-safe and can be interleaved
arbitrarily on the same descriptor. - Download from csapp.cs.cmu.edu/public/ics/code/src
/csapp.c csapp.cs.cmu.edu/public/ics/code/include/
csapp.h
49Unbuffered RIO Input and Output
- Same interface as Unix read and write
- Especially useful for transferring data on
network sockets - rio_readn returns short count only if it
encounters EOF. - rio_writen never returns a short count.
- Calls to rio_readn and rio_writen can be
interleaved arbitrarily on the same descriptor.
include csapp.h ssize_t rio_readn(int fd,
void usrbuf, size_t n) ssize_t rio_writen(nt
fd, void usrbuf, size_t n) Return num.
bytes transferred if OK, 0 on EOF (rio_readn
only), -1 on error
50Implementation of rio_readn
/ rio_readn - robustly read n bytes
(unbuffered) / ssize_t rio_readn(int fd, void
usrbuf, size_t n) size_t nleft n
ssize_t nread char bufp usrbuf
while (nleft gt 0) if ((nread read(fd, bufp,
nleft)) lt 0) if (errno EINTR) /
interrupted by sig
handler return / nread 0 / and
call read() again / else return -1
/ errno set by read() / else if (nread
0) break / EOF / nleft -
nread bufp nread return (n -
nleft) / return gt 0 /
51Buffered RIO Input Functions
- Efficiently read text lines and binary data from
a file partially cached in an internal memory
buffer - rio_readlineb reads a text line of up to maxlen
bytes from file fd and stores the line in usrbuf. - Especially useful for reading text lines from
network sockets. - rio_readnb reads up to n bytes from file fd.
- Calls to rio_readlineb and rio_readnb can be
interleaved arbitrarily on the same descriptor. - Warning Dont interleave with calls to rio_readn
include csapp.h void rio_readinitb(rio_t rp,
int fd) ssize_t rio_readlineb(rio_t rp, void
usrbuf, size_t maxlen) ssize_t rio_readnb(rio_t
rp, void usrbuf, size_t n)
Return num. bytes read if OK, 0 on EOF, -1 on
error
52RIO Example
- Copying the lines of a text file from standard
input to standard output.
include "csapp.h" int main(int argc, char
argv) int n rio_t rio char
bufMAXLINE Rio_readinitb(rio,
STDIN_FILENO) while((n Rio_readlineb(rio,
buf, MAXLINE)) ! 0) Rio_writen(STDOUT_FILENO,
buf, n) exit(0)
53Pros and Cons of Unix I/O
- Pros
- Unix I/O is the most general and lowest overhead
form of I/O. - All other I/O packages are implemented using Unix
I/O functions. - Unix I/O provides functions for accessing file
metadata. - Cons
- Dealing with short counts is tricky and error
prone. - Efficient reading of text lines requires some
form of buffering, also tricky and error prone. - Both of these issues are addressed by the
standard I/O and RIO packages.
54Wrapup
- Dynamic memory allocation
- Key policies
- Placement
- Splitting
- Coalescing
- UNIX I/O
- Everything's a file
- Accessed through descriptors
- read/write/close
- Short reads are an issue
- Reading
- 10.9 10.11
- 11.1 11.4
- Pickup HW4 Malloclab
- Have a good turkey day!
- No class on Wednesday