|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 221-222 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 221
190
MEMORY MANAGEMENT
CHAP. 3
If it is expected that most processes will grow as they run, it is probably a good
idea to allocate a little extra memory whenever a process is swapped in or moved,
to reduce the overhead associated with moving or swapping processes that no long-
er fit in their allocated memory. However, when swapping processes to disk, only
the memory actually in use should be swapped; it is wasteful to swap the extra
memory as well.
In Fig. 3-5(a) we see a memory configuration in which space for
growth has been allocated to two processes.
(a)
(b)
Operating
system
Room for growth
Room for growth
B-Stack
A-Stack
B-Data
A-Data
B-Program
A-Program
Operating
system
Room for growth
B
A
Actually in use
Room for growth
Actually in use
Figure 3-5.
(a) Allocating space for a growing data segment. (b) Allocating
space for a growing stack and a growing data segment.
If processes can have two growing segments—for example, the data segment
being used as a heap for variables that are dynamically allocated and released and a
stack segment for the normal local variables and return addresses—an alternative
arrangement suggests itself, namely that of Fig. 3-5(b). In this figure we see that
each process illustrated has a stack at the top of its allocated memory that is grow-
ing downward, and a data segment just beyond the program text that is growing
upward. The memory between them can be used for either segment. If it runs out,
the process will either have to be moved to a hole with sufficient space, swapped
out of memory until a large enough hole can be created, or killed.
3.2.3 Managing Free Memory
When memory is assigned dynamically, the operating system must manage it.
In general terms, there are two ways to keep track of memory usage: bitmaps and
free lists.
In this section and the next one we will look at these two methods. In
Page 222
SEC. 3.2
A MEMORY ABSTRACTION: ADDRESS SPACES
191
Chapter 10, we will look at some specific memory allocators used in Linux (like
buddy and slab allocators) in more detail.
Memory Management with Bitmaps
With a bitmap, memory is divided into allocation units as small as a few words
and as large as several kilobytes. Corresponding to each allocation unit is a bit in
the bitmap, which is 0 if the unit is free and 1 if it is occupied (or vice versa). Fig-
ure 3-6 shows part of memory and the corresponding bitmap.
(a)
(b)
(c)
A
B
C
D
E
8
16
24
Hole
Starts
at 18
Length
2
Process
P
0
5
H
5
3
P
8
6
P
14
4
H
18
2
P
20
6
P
26
3
H
29
3
X
1 1 1 1 1 0 0 0
1 1 1 1 1 1 1 1
1 1 0 0 1 1 1 1
1 1 1 1 1 0 0 0
Figure 3-6.
(a) A part of memory with five processes and three holes. The tick
marks show the memory allocation units. The shaded regions (0 in the bitmap)
are free.
(b) The corresponding bitmap.
(c) The same information as a list.
The size of the allocation unit is an important design issue. The smaller the al-
location unit, the larger the bitmap.
However, even with an allocation unit as small
as 4 bytes, 32 bits of memory will require only 1 bit of the map.
A memory of 32
n
bits will use
n
map bits, so the bitmap will take up only 1/32 of memory.
If the al-
location unit is chosen large, the bitmap will be smaller, but appreciable memory
may be wasted in the last unit of the process if the process size is not an exact mul-
tiple of the allocation unit.
A bitmap provides a simple way to keep track of memory words in a fixed
amount of memory because the size of the bitmap depends only on the size of
memory and the size of the allocation unit. The main problem is that when it has
been decided to bring a
k
-unit process into memory, the memory manager must
search the bitmap to find a run of
k
consecutive 0 bits in the map. Searching a bit-
map for a run of a given length is a slow operation (because the run may straddle
word boundaries in the map); this is an argument against bitmaps.
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades
Know more
Students also viewed documents
lab 18.docx
lab_18.docx
Course
Course
3
Module5QuizSTA2023.d...
Module5QuizSTA2023.docx.docx
Course
Course
10
Week 7 Test Math302....
Week_7_Test_Math302.docx.docx
Course
Course
30
Chapter 1 Assigment ...
Chapter_1_Assigment_Questions.docx.docx
Course
Course
5
Week 4 tests.docx.do...
Week_4_tests.docx.docx
Course
Course
23
Week 6 tests.docx.do...
Week_6_tests.docx.docx
Course
Course
106
