Computer Systems Lab Stefan M. Freudenberger Computer Systems, ETH - - PowerPoint PPT Presentation

▶
computer systems lab
SMART_READER_LITE
LIVE PREVIEW

Computer Systems Lab Stefan M. Freudenberger Computer Systems, ETH - - PowerPoint PPT Presentation

Jul 22, 2023 152 likes •465 views

Computer Systems Lab Stefan M. Freudenberger Computer Systems, ETH Zrich Introduction Course Schedule Lecture: Monday 4:15 5:00 p.m. (RZ F21) Recitation: TBD Assignments: in teams, time to be arranged individually

slide-1
SLIDE 1

Computer Systems Lab

Stefan M. Freudenberger

Computer Systems, ETH Zürich

slide-2
SLIDE 2

Introduction

  • Course Schedule
  • Lecture: Monday 4:15 – 5:00 p.m. (RZ F21)
  • Recitation: TBD
  • Assignments: in teams, time to be arranged individually
  • Contact
  • Stefan Freudenberger, RZ H8.1, stefan.freudenberger@inf.ethz.ch
  • TBD
  • Resources
  • http://www.lst.inf.ethz.ch/teaching/lectures/current/2100/index.php

2011-02-28 2 Computer Systems Lab

slide-3
SLIDE 3

Course schedule (tentative)

Date Lecture Project 2011-02-21 Introduction 2011-02-28 Memory Allocation Team registration – due 2011-03-03 2011-03-07 Computer Science Colloquium - Prof. Dr. David Padua: And the Answer Is: Automatic Parallel Programming. Starts at 16:15 CAB G61 (ends at ca. 17:20) Malloc Lab – due 2011-03-20 2011-03-14 2011-03-21 – due 2011-04-03 2011-03-28 2011-04-04 – due 2011-04-17 2011-04-11 Sechseläuten: holiday 2011-04-18 2011-04-25 Easter Monday: holiday 2011-05-02 – due 2011-05-15 2011-05-09 2011-05-16 – due 2011-05-29 2011-05-23 2011-05-30

2011-02-28 3 Computer Systems Lab

slide-4
SLIDE 4

Admin

Team registration:

  • E-mail with team members:
  • Include names, legi numbers, nethz-logins
  • Subject: “CSLab: …”
  • Due: Thursday, March 3
  • Get team name assignment back
  • Due: Monday, March 7
  • Check that you can access your team’s area:
  • Do this early!
  • Assignment will be posted on the web site on

Monday, March 7

  • Assignment will be due midnight March 20

2011-02-28 4 Computer Systems Lab

slide-5
SLIDE 5

Project 1: Memory Allocation

  • Summary
  • Implement a memory allocator: malloc, free, realloc
  • Goals
  • Learn how to manage storage allocation
  • Good exercise to master pointers
  • Environment
  • Unix like system
  • C
  • Resources
  • Computer Systems — A Programmer’s Perspective, Chapter 10.9

(Dynamic Memory Allocation), pages 730–755 (1st Edition).

2011-02-28 5 Computer Systems Lab

slide-6
SLIDE 6

The Heap

Area of a process’s (virtual) memory that is dynamically allocated

  • Example (Unix)
  • Grows upwards
  • The brk pointer marks the top of the

heap

2011-02-28

User stack Memory mapped region for shared libraries Heap Uninitialized data (.bss) Initialized data (.data) Program (.text) Top of the heap (brk)

6 Computer Systems Lab

slide-7
SLIDE 7

Memory Management

The memory manager (user space) maintains a process’s heap: a collection of blocks (contiguous chunks of memory) which are either allocated or free

  • Allocation is explicit (e.g., malloc in C or new in Java)
  • Deallocation can be:
  • explict (e.g., free in C, delete in C++)
  • implicit (garbage collection in Java, .NET)

Issues

  • The memory manager needs to:
  • Distinguish block boundaries
  • Distinguish between free and allocated blocks

2011-02-28 7 Computer Systems Lab

slide-8
SLIDE 8

Memory Allocation: Strategies

  • first-fit: use the first free block which is big enough
  • best-fit: take smallest fitting block
  • worst-fit: take biggest available block
  • quick-fit: best-fit but multiple free-lists (one per block size)

2011-02-28

32 8 16 8 16 32 8 8 32 16 8 8 32 16 16 64 8 16 8 32

8 Computer Systems Lab

slide-9
SLIDE 9

Memory Allocation: Bitmaps

The simplest (but often slowest) way to manage memory blocks is to mark in a bitmap if a block is free or allocated

  • Space
  • For a 4GB memory space and 4KB blocks a 128MB table is

necessary to store the free/allocated information

  • Speed
  • Slow scan to find a free block

2011-02-28

32 8 16 8 16 32 8 8 32 16 8 8 32 16 16 64 8 16 8 32 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

9 Computer Systems Lab

slide-10
SLIDE 10

Memory Allocation: Dynamic Data Structures

  • Free blocks are stored in a dynamic data structure
  • For example, ordered list, ordered tree, …
  • Lists are usually ordered by allocation address to allow a faster

merging of free blocks

2011-02-28

32 8 16 8 16 32 8 8 32 16 8 8 32 16 16 64 8 16 8 32

free list

10 Computer Systems Lab

slide-11
SLIDE 11

Memory Allocation: Dynamic Data Structures

  • Free blocks are stored in a dynamic data structure
  • For example, ordered list, ordered tree, …
  • Lists are usually ordered by allocation address to allow a faster

merging of free blocks

  • When two adjacent blocks are both free, they are coalesced into a single block
  • Initially:
  • After free:
  • After coalescing:

2011-02-28

8 16 8 8 16 8 32

11 Computer Systems Lab

slide-12
SLIDE 12

Memory Allocation: Lists

  • Space
  • Link information as well as some flags (i.e., free or allocated) has

to be stored in the block

  • Speed
  • Depending on the chosen data structure operations can be

implemented efficiently

2011-02-28 12 Computer Systems Lab

slide-13
SLIDE 13

Block Format

Most allocators store information (allocated/free, size, …) in the blocks themselves

  • Example:
  • Link information:
  • implicit: blocks are traversed using the size field only
  • explicit: link information is embedded in the block

2011-02-28

payload size flags padding (optional) payload size flags link information padding (optional) ptr ptr

13 Computer Systems Lab

slide-14
SLIDE 14

Block Format (Footers)

Implicit allocators have the problem that to perform coalescing they need information about the previous block.

  • Knuth [1973] suggested to put a copy
  • f the block header at the end of the

block (footer)

  • When freeing a block an implicit allocator

can then check the header of the next block and the footer of the previous one

  • Footers are not necessary for allocated

blocks if we store the allocated/free information in the header of the next block

  • D. E. Knuth. The Art of Computer Programming. Addison

Wesley, 1973. Volume 1, Chapter 2, pp. 228–463.

2011-02-28

payload size flags link information padding (optional) size flags

14 Computer Systems Lab

slide-15
SLIDE 15

Memory Allocation: Space Utilization

  • External fragmentation
  • Unused space among the blocks – depends on the allocation

strategy

  • Internal fragmentation
  • Unused space inside the blocks – depends on the possible block

sizes (granularity)

  • Data structures
  • Space used to maintain data structures cannot be allocated

(bitmaps, pointers, flags, …)

2011-02-28 15 Computer Systems Lab

slide-16
SLIDE 16

Memory Allocation: Buddy System

  • An example of allocation strategy:
  • Each block has a size of 2k
  • The system maintains a list for each size
  • Block allocation:
  • Find a block which fits
  • If necessary split a larger block, and put the remaining part in the correct list
  • Free:
  • Mark the block as free
  • If is possible merge with a free neighbor
  • The buddy system is used in several operating systems

(Windows, Linux, Oberon, …).

2011-02-28 16 Computer Systems Lab

slide-17
SLIDE 17

Memory Allocation: Buddy System (example)

  • Free:
  • Initial:

2011-02-28

8 8 16 8 8 16 16 32 Free list:

17 Computer Systems Lab

slide-18
SLIDE 18

Memory Allocation: Buddy System (example)

  • Free:
  • Initial:
  • Free:

2011-02-28

8 8 16 8 8 16 16 32 Free list: 8 8 16 8

18 Computer Systems Lab

slide-19
SLIDE 19

Memory Allocation: Buddy System (example)

  • Free:
  • Initial:
  • Free:
  • Coalesce:

2011-02-28

8 8 16 8 16 16 32 Free list: 8 8 16 16 16 16

19 Computer Systems Lab

slide-20
SLIDE 20

Memory Allocation: Buddy System (example)

  • Free:
  • Initial:
  • Free:
  • Coalesce:
  • Coalesce again:

2011-02-28

8 8 16 8 16 32 Free list: 8 8 16 16 16 32 32

20 Computer Systems Lab

slide-21
SLIDE 21

Memory Allocation: Buddy System (example)

  • Allocate(8):
  • Initial:

2011-02-28

8 16 32 Free list: 32 32

21 Computer Systems Lab

slide-22
SLIDE 22

Memory Allocation: Buddy System (example)

  • Allocate(8):
  • Initial:
  • Split free block:

2011-02-28

8 16 32 Free list: 32 16 16 16 16

22 Computer Systems Lab

slide-23
SLIDE 23

Memory Allocation: Buddy System (example)

  • Allocate(8):
  • Initial:
  • Split free block:
  • Split free block again:

2011-02-28

8 16 32 Free list: 32 16 16 8 8 16 8 16 8

23 Computer Systems Lab

slide-24
SLIDE 24

Memory Allocation: Buddy System (example)

  • Allocate(8):
  • Initial:
  • Split free block:
  • Split free block again:
  • Allocate:

2011-02-28

8 16 32 Free list: 32 16 16 8 8 16 8 16 8 8 16

24 Computer Systems Lab

slide-25
SLIDE 25

Memory Allocation: Slab Allocator

  • Disadvantages of the buddy system:
  • Internal fragmentation (max 50%)
  • Bad distribution of the block addresses (bad caches performance)
  • Solaris introduced the concept of a slab allocator:
  • Based on the idea that processes are likely to request a lot of objects
  • f the same size: these objects can be kept and reused
  • Slabs are collections of objects of the same size
  • Sizes (and addresses) are not geometrically distributed
  • Used by AmigaOS (4), Linux (≥ 2.2) and Solaris (≥ 2.4)
  • J. Bonwick. The Slab Allocator: An Object-Caching Kernel Memory
  • Allocator. Proc. 1994 USENIX Annual Tech. Conf, pp. 87–98, June 1994,

Boston, MA.

2011-02-28 25 Computer Systems Lab

slide-26
SLIDE 26

Lab: Task

  • Write a dynamic memory allocator, i.e., implement:
  • malloc
  • free
  • realloc
  • Goals of the lab:
  • Understand how a real memory allocator works
  • Evaluate different design strategies
  • A nice exercise for low level C programming

2011-02-28 26 Computer Systems Lab

slide-27
SLIDE 27

Lab: Task

  • void* mm_malloc(size_t size)
  • Returns a pointer to a memory block of at least size bytes
  • 8 byte aligned
  • If no allocation is possible returns NULL
  • void mm_free(void* ptr)
  • Frees the block pointed to by ptr
  • If ptr is not the first address of an allocated block the behavior is

undefined

2011-02-28 27 Computer Systems Lab

slide-28
SLIDE 28

Lab: Task

  • void* mm realloc(void* ptr, size_t size)
  • If ptr is NULL: mm_malloc(size)
  • If size is 0: the allocated memory block is reduced in size to zero

bytes and a non-NULL pointer is returned (which cannot be directly dereferenced, since it points to no allocated memory, but it can be used in future calls to realloc and free)(this is the c99 definition)

  • Returns a pointer to a new block of size bytes and with the same

content as the block pointed by ptr (up to the minimum of the old and new sizes)

2011-02-28 28 Computer Systems Lab

slide-29
SLIDE 29

Lab: Framework Provided

  • We provide one of the simplest possible implementations:
  • malloc: sequentially allocate a block increasing the top of heap

pointer (brk)

  • free: do nothing
  • realloc: allocate a new block with the requested size

Although this solution is formally correct and very fast, it has a very bad space utilization.

2011-02-28 29 Computer Systems Lab

slide-30
SLIDE 30

Lab: Design

  • First, think about the design of your memory allocator:
  • Choose the allocation strategy: first fit, best fit, …
  • Choose a data structure(s): ordered list, binary tree, …
  • Think on how to mark the blocks: in general how to store the size of

the block, the free tag and the eventual pointers to manage the data structure (e.g., next pointer for a list, left, right for tree, …)

  • Think about the API of the functions to manage your structure

(flexibility)

  • Choose a time to perform coalescing (merging):
  • immediate (i.e., when putting a block on the free list)
  • deferred (e.g., when allocation fails)

2011-02-28 30 Computer Systems Lab

slide-31
SLIDE 31

Lab: Design

  • How to choose the correct strategy?
  • Analyze the needs (space, speed, predictability)
  • Analyze the environment (experimentally)
  • Test different strategies

2011-02-28 31 Computer Systems Lab