Memory Management Algorithms and Implementation

in C C 1st Edition Bill Blunden pdf download

https://ebookgate.com/product/memory-management-algorithms-and-
implementation-in-c-c-1st-edition-bill-blunden/

Get Instant Ebook Downloads – Browse at https://ebookgate.com

Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

Data Structures and Algorithms in C 1st Edition Michael

Mcmillan

https://ebookgate.com/product/data-structures-and-algorithms-in-c-1st-
edition-michael-mcmillan/

ebookgate.com

Parallel Scientific Computing in C and MPI A Seamless

Approach to Parallel Algorithms and their Implementation
1st edition Edition George Em Karniadakis
https://ebookgate.com/product/parallel-scientific-computing-in-c-and-
mpi-a-seamless-approach-to-parallel-algorithms-and-their-
implementation-1st-edition-edition-george-em-karniadakis/
ebookgate.com

Data Structures and Algorithms in C 4th Edition Adam

Drozdek

https://ebookgate.com/product/data-structures-and-algorithms-in-c-4th-
edition-adam-drozdek/

ebookgate.com

Memory War and Trauma Nigel C. Hunt

https://ebookgate.com/product/memory-war-and-trauma-nigel-c-hunt/

ebookgate.com
Data Structures Algorithms And Applications In C 2nd
Edition Sartaj Sahni

https://ebookgate.com/product/data-structures-algorithms-and-
applications-in-c-2nd-edition-sartaj-sahni/

ebookgate.com

Effective C 50 Specific Ways to Improve Your C 1st Edition

Bill Wagner

https://ebookgate.com/product/effective-c-50-specific-ways-to-improve-
your-c-1st-edition-bill-wagner/

ebookgate.com

Data Clustering Algorithms and Applications 1st Edition

Charu C. Aggarwal

https://ebookgate.com/product/data-clustering-algorithms-and-
applications-1st-edition-charu-c-aggarwal/

ebookgate.com

Data Structures and Algorithms Using C 1st Edition Michael

Mcmillan

https://ebookgate.com/product/data-structures-and-algorithms-
using-c-1st-edition-michael-mcmillan/

ebookgate.com

Offshoring IT The Good the Bad and the Ugly 1st Edition
Bill Blunden (Auth.)

https://ebookgate.com/product/offshoring-it-the-good-the-bad-and-the-
ugly-1st-edition-bill-blunden-auth/

ebookgate.com
Memory Management
Algorithms and
Implementation in C/C++

by
Bill Blunden

Wordware Publishing, Inc.

Library of Congress Cataloging-in-Publication Data

Blunden, Bill, 1969-

Memory management: algorithms and implementation in C/C++ / by
Bill Blunden.
p. cm.
Includes bibliographical references and index.
ISBN 1-55622-347-1
1. Memory management (Computer science) 2. Computer algorithms.
3. C (Computer program language) 4. C++ (Computer program
language) I. Title.
QA76.9.M45 .B558 2002
005.4'35--dc21 2002012447
CIP

© 2003, Wordware Publishing, Inc.

All Rights Reserved
2320 Los Rios Boulevard
Plano, Texas 75074

No part of this book may be reproduced in any form or by

any means without permission in writing from
Wordware Publishing, Inc.

Printed in the United States of America

ISBN 1-55622-347-1
10 9 8 7 6 5 4 3 2 1
0208

Product names mentioned are used for identification purposes only and may be trademarks of
their respective companies.

All inquiries for volume purchases of this book should be addressed to Wordware
Publishing, Inc., at the above address. Telephone inquiries may be made by calling:
(972) 423-0090
 This book is dedicated to Rob, Julie, and Theo.

And also to David M. Lee

“I came to learn physics, and I got Jimmy Stewart”

iii
Table of Contents

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . xi
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Chapter 1 Memory Management Mechanisms. . . . . . . . . 1

Mechanism Versus Policy . . . . . . . . . . . . . . . . . . 1
Memory Hierarchy . . . . . . . . . . . . . . . . . . . . . . 3
Address Lines and Buses. . . . . . . . . . . . . . . . . . . 9
Intel Pentium Architecture . . . . . . . . . . . . . . . . . 11
Real Mode Operation. . . . . . . . . . . . . . . . . . . 14
Protected Mode Operation. . . . . . . . . . . . . . . . 18
Protected Mode Segmentation . . . . . . . . . . . . 19
Protected Mode Paging . . . . . . . . . . . . . . . . 26
Paging as Protection . . . . . . . . . . . . . . . . . . 31
Addresses: Logical, Linear, and Physical . . . . . . . 33
Page Frames and Pages . . . . . . . . . . . . . . . . 34
Case Study: Switching to Protected Mode . . . . . . . 35
Closing Thoughts . . . . . . . . . . . . . . . . . . . . . . 42
References . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Chapter 2 Memory Management Policies. . . . . . . . . . . 45

Case Study: MS-DOS . . . . . . . . . . . . . . . . . . . . 46
DOS Segmentation and Paging . . . . . . . . . . . . . 46
DOS Memory Map . . . . . . . . . . . . . . . . . . . . 47
Memory Usage . . . . . . . . . . . . . . . . . . . . . . 49
Example: A Simple Video Driver . . . . . . . . . . . . 50
Example: Usurping DOS . . . . . . . . . . . . . . . . . 52
Jumping the 640KB Hurdle . . . . . . . . . . . . . . . 56
Case Study: MMURTL . . . . . . . . . . . . . . . . . . . 59
Background and Design Goals . . . . . . . . . . . . . . 60
MMURTL and Segmentation . . . . . . . . . . . . . . 61
Paging Variations . . . . . . . . . . . . . . . . . . . . . 63
MMURTL and Paging . . . . . . . . . . . . . . . . . . 64

v
Table of Contents

Memory Allocation . . . . . . . . . . . . . . . . . . . . 66
Case Study: Linux . . . . . . . . . . . . . . . . . . . . . . 67
History and MINIX . . . . . . . . . . . . . . . . . . . . 67
Design Goals and Features. . . . . . . . . . . . . . . . 68
Linux and Segmentation . . . . . . . . . . . . . . . . . 69
Linux and Paging . . . . . . . . . . . . . . . . . . . . . 72
Three-Level Paging . . . . . . . . . . . . . . . . . . 72
Page Fault Handling . . . . . . . . . . . . . . . . . . 76
Memory Allocation . . . . . . . . . . . . . . . . . . . . 76
Memory Usage . . . . . . . . . . . . . . . . . . . . . . 81
Example: Siege Warfare . . . . . . . . . . . . . . . . . 82
Example: Siege Warfare, More Treachery . . . . . . . 87
Case Study: Windows . . . . . . . . . . . . . . . . . . . . 92
Historical Forces . . . . . . . . . . . . . . . . . . . . . 92
Memory Map Overview . . . . . . . . . . . . . . . . . 96
Windows and Segmentation . . . . . . . . . . . . . . . 99
Special Weapons and Tactics . . . . . . . . . . . . . 99
Crashing Windows with a Keystroke . . . . . . . . 102
Reverse Engineering the GDT . . . . . . . . . . . 102
Windows and Paging . . . . . . . . . . . . . . . . . . 105
Linear Address Space Taxonomy . . . . . . . . . . 105
Musical Chairs for Pages. . . . . . . . . . . . . . . 106
Memory Protection . . . . . . . . . . . . . . . . . 108
Demand Paging . . . . . . . . . . . . . . . . . . . . 109
Memory Allocation . . . . . . . . . . . . . . . . . . . 110
Memory Usage . . . . . . . . . . . . . . . . . . . . . 114
Turning Off Paging . . . . . . . . . . . . . . . . . . . 117
Example: Things That Go Thunk in the Night . . . . 118
Closing Thoughts . . . . . . . . . . . . . . . . . . . . . 122
References . . . . . . . . . . . . . . . . . . . . . . . . . 123
Books and Articles . . . . . . . . . . . . . . . . . . . 123
Web Sites . . . . . . . . . . . . . . . . . . . . . . . . 125

Chapter 3 High-Level Services. . . . . . . . . . . . . . . . 127

View from 10,000 Feet . . . . . . . . . . . . . . . . . . . 127
Compiler-Based Allocation . . . . . . . . . . . . . . . . 129
Data Section . . . . . . . . . . . . . . . . . . . . . . . 132
Code Section . . . . . . . . . . . . . . . . . . . . . . 134
Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Activation Records . . . . . . . . . . . . . . . . . . 138
Scope . . . . . . . . . . . . . . . . . . . . . . . . . 144

vi
 Table of Contents

Static or Dynamic? . . . . . . . . . . . . . . . . . . 150

Heap Allocation . . . . . . . . . . . . . . . . . . . . . . 151
System Call Interface . . . . . . . . . . . . . . . . . . 151
The Heap . . . . . . . . . . . . . . . . . . . . . . . . 156
Manual Memory Management. . . . . . . . . . . . 157
Example: C Standard Library Calls . . . . . . . . . 158
Automatic Memory Management . . . . . . . . . . 160
Example: The BDW Conservative Garbage Collector
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Manual Versus Automatic?. . . . . . . . . . . . . . 164
The Evolution of Languages. . . . . . . . . . . . . . . . 168
Case Study: COBOL . . . . . . . . . . . . . . . . . . 171
Case Study: FORTRAN. . . . . . . . . . . . . . . . . 177
Case Study: Pascal . . . . . . . . . . . . . . . . . . . 181
Case Study: C . . . . . . . . . . . . . . . . . . . . . . 184
Case Study: Java. . . . . . . . . . . . . . . . . . . . . 192
Language Features . . . . . . . . . . . . . . . . . . 192
Virtual Machine Architecture . . . . . . . . . . . . 194
Java Memory Management . . . . . . . . . . . . . 196
Memory Management: The Three-layer Cake . . . . . . 202
References . . . . . . . . . . . . . . . . . . . . . . . . . 204

Chapter 4 Manual Memory Management . . . . . . . . . . 207

Replacements for malloc() and free() . . . . . . . 207
System Call Interface and Porting Issues . . . . . . . . 208
Keep It Simple . . . Stupid! . . . . . . . . . . . . . . . . . 211
Measuring Performance . . . . . . . . . . . . . . . . . . 212
The Ultimate Measure: Time . . . . . . . . . . . . . 212
ANSI and Native Time Routines . . . . . . . . . . 213
The Data Distribution: Creating Random Variates . 215
Testing Methodology . . . . . . . . . . . . . . . . . . 219
Indexing: The General Approach . . . . . . . . . . . . . 224
malloc() Version 1: Bitmapped Allocation. . . . . . . 224
Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Implementation . . . . . . . . . . . . . . . . . . . . . 226
tree.cpp . . . . . . . . . . . . . . . . . . . . . . . . 227
bitmap.cpp . . . . . . . . . . . . . . . . . . . . . . 232
memmgr.cpp . . . . . . . . . . . . . . . . . . . . . 236
mallocV1.cpp . . . . . . . . . . . . . . . . . . . . . 239
perform.cpp . . . . . . . . . . . . . . . . . . . . . . 241
driver.cpp . . . . . . . . . . . . . . . . . . . . . . . 241

vii
Table of Contents

Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . 247
malloc() Version 2: Sequential Fit . . . . . . . . . . . 248
Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Implementation . . . . . . . . . . . . . . . . . . . . . 251
memmgr.cpp . . . . . . . . . . . . . . . . . . . . . 251
mallocV2.cpp . . . . . . . . . . . . . . . . . . . . . 260
driver.cpp . . . . . . . . . . . . . . . . . . . . . . . 261
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . 264
malloc() Version 3: Segregated Lists . . . . . . . . . 265
Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Implementation . . . . . . . . . . . . . . . . . . . . . 266
memmgr.cpp . . . . . . . . . . . . . . . . . . . . . 267
mallocV3.cpp . . . . . . . . . . . . . . . . . . . . . 274
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . 279
Performance Comparison . . . . . . . . . . . . . . . . . 279

Chapter 5 Automatic Memory Management . . . . . . . . 281

Garbage Collection Taxonomy . . . . . . . . . . . . . . 281
malloc() Version 4: Reference Counting . . . . . . . 283
Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Implementation . . . . . . . . . . . . . . . . . . . . . 284
driver.cpp . . . . . . . . . . . . . . . . . . . . . . . 285
mallocV4.cpp . . . . . . . . . . . . . . . . . . . . . 287
perform.cpp . . . . . . . . . . . . . . . . . . . . . . 288
memmgr.cpp . . . . . . . . . . . . . . . . . . . . . 289
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . 302
malloc() Version 5: Mark-Sweep . . . . . . . . . . . 304
Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Implementation . . . . . . . . . . . . . . . . . . . . . 307
driver.cpp . . . . . . . . . . . . . . . . . . . . . . . 307
mallocV5.cpp . . . . . . . . . . . . . . . . . . . . . 309
perform.cpp . . . . . . . . . . . . . . . . . . . . . . 311
memmgr.cpp . . . . . . . . . . . . . . . . . . . . . 312
Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . 330
Performance Comparison . . . . . . . . . . . . . . . . . 332
Potential Additions . . . . . . . . . . . . . . . . . . . . . 332

viii
 Table of Contents

Object Format Assumptions . . . . . . . . . . . . . . 333

Variable Heap Size . . . . . . . . . . . . . . . . . . . 335
Indirect Addressing . . . . . . . . . . . . . . . . . . . 335
Real-Time Behavior . . . . . . . . . . . . . . . . . . . 337
Life Span Characteristics . . . . . . . . . . . . . . . . 338
Multithreaded Support . . . . . . . . . . . . . . . . . 339

Chapter 6 Miscellaneous Topics . . . . . . . . . . . . . . . 343

Suballocators . . . . . . . . . . . . . . . . . . . . . . . . 343
Monolithic Versus Microkernel Architectures . . . . . . 348
Closing Thoughts . . . . . . . . . . . . . . . . . . . . . 351

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

ix
Acknowledgments

Publishing a book is an extended process that involves a number of

people. Writing the final manuscript is just a small part of the big
picture. This section is dedicated to all the people who directly, and
indirectly, lent me their help.
First and foremost, I would like to thank Jim Hill of Wordware
Publishing for giving me the opportunity to write a book and believ-
ing in me. I would also like to extend thanks to Wes Beckwith and
Beth Kohler. Wes, in addition to offering constant encouragement,
does a great job of putting up with my e-mails and handling the vari-
ous packages that I send. Beth Kohler, who performed the
incredible task of reading my first book for Wordware in a matter of
days, has also been invaluable.
I first spoke with Barry Brey back in the mid-1990s when I
became interested in protected mode programming. He has always
taken the time to answer my questions and offer his insight. Barry
wrote the first book on the Intel chip set back in 1984. Since then,
he has written well over 20 books. His current textbook on Intel’s
IA32 processors is in its sixth edition. This is why I knew I had to
ask Barry to be the technical editor for this book. Thanks, Barry.
“Look, our middleware even runs on that little Windows
NT piece of crap.”
— George Matkovitz
“Hey, who was the %&^$ son of a &*$# who wrote this
optimized load of . . . oh, it was me.”
— Mike Adler
Mike Adler and George Matkovitz are two old fogeys who worked at
Control Data back when Seymour Cray kicked the tar out of IBM.
George helped to implement the world’s first message-passing
operating system at Control Data. Mike also worked on a number of
groundbreaking system software projects. I met these two codgers
while performing R&D for an ERP vendor in the Midwest. I hadn’t
noticed how much these engineers had influenced me until I left

xi
Acknowledgments

Minnesota for California. It was almost as though I had learned

through osmosis. A lot of my core understanding of software and
the computer industry in general is based on the bits of hard-won
advice and lore that these gentlemen passed on to me. I distinctly
remember walking into Mike’s office and asking him, “Hey Mike,
how do you build an operating system?”
I would also like to thank Frank Merat, a senior professor at Case
Western Reserve University. Frank has consistently shown interest
in my work and has offered his support whenever he could. There is
no better proving ground for a book than an established research
university.
Finally, I would like to thank SonicWALL, Inc. for laying me off
and giving me the opportunity to sit around and think. The days I
spent huddled with my computers were very productive.

xii
Introduction

“Pay no attention to the man behind the curtain.”

— The Wizard of Oz

There are a multitude of academic computer science texts that dis-

cuss memory management. They typically devote a chapter or less
to the subject and then move on. Rarely are concrete, machine-level
details provided, and actual source code is even scarcer. When the
author is done with his whirlwind tour, the reader tends to have a
very limited idea about what is happening behind the curtain. This
is no surprise, given that the nature of the discussion is rampantly
ambiguous. Imagine trying to appreciate Beethoven by having
someone read the sheet music to you or experience the Mona Lisa
by reading a description in a guidebook.
This book is different. Very different.
In this book, I am going to pull the curtain back and let you see
the little man operating the switches and pulleys. You may be
excited by what you see, or you may feel sorry that you decided to
look. But as Enrico Fermi would agree, knowledge is always better
than ignorance.
This book provides an in-depth look at memory subsystems and
offers extensive source code examples. In cases where I do not
have access to source code (i.e., Windows), I offer advice on how to
gather forensic evidence, which will nurture insight. While some
books only give readers a peak under the hood, this book will give
readers a power drill and allow them to rip out the transmission.
The idea behind this is to allow readers to step into the garage and
get their hands dirty.
My own experience with memory managers began back in the
late 1980s when Borland’s nifty Turbo C 1.0 compiler was released.
This was my first taste of the C language. I can remember using a
disassembler to reverse engineer library code in an attempt to see
how the malloc() and free() standard library functions

xiii
Introduction

operated. I don’t know how many school nights I spent staring at an

80x25 monochrome screen, deciphering hex dumps. It was tough
going and not horribly rewarding (but I was curious, and I couldn’t
help myself). Fortunately, I have done most of the dirty work for
you. You will conveniently be able to sidestep all of the hurdles and
tedious manual labor that confronted me.
If you were like me and enjoyed taking your toys apart when you
were a child to see how they worked, then this is the book for you.
So lay your computer on a tarpaulin, break out your compilers, and
grab an oil rag. We’re going to take apart memory management sub-
systems and put them back together. Let the dust fly where it may!

Historical Setting
In the late 1930s, a group of scholars arrived at Bletchley Park in an
attempt to break the Nazis’ famous Enigma cipher. This group of
codebreakers included a number of notable thinkers, like Tommy
Flowers and Alan Turing. As a result of the effort to crack Enigma,
the first electronic computer was constructed in 1943. It was named
Colossus and used thermionic valves (known today as vacuum tubes)
for storing data. Other vacuum tube computers followed. For exam-
ple, ENIAC (electronic numerical integrator and computer) was
built by the U.S. Army in 1945 to compute ballistic firing tables.

NOTE Science fiction aficionados might enjoy a movie called Colos-

sus: The Forbin Project. It was made in 1969 and centers around
Colossus, a supercomputer designed by a scientist named Charles
Forbin. Forbin convinces the military that they should give control of
the U.S. nuclear arsenal to Colossus in order to eliminate the potential
of human error accidentally starting World War III. The movie is similar
in spirit to Stanley Kubrick’s 2001: A Space Odyssey, but without the
happy ending: Robot is built, robot becomes sentient, robot runs
amok. I was told that everyone who has ever worked at Control Data
has seen this movie.

The next earth-shaking development arrived in 1949 when ferrite

(iron) core memory was invented. Each bit of memory was made of
a small, circular iron magnet. The value of the bit switched from “1”
to “0” by using electrical wires to magnetize the circular loops in
one of two possible directions. The first computer to utilize ferrite
core memory was IBM’s 705, which was put into production in
1955. Back in those days, 8KB of memory was considered a huge
piece of real estate.

xiv
 Introduction

Everything changed once transistors became the standard way to

store bits. The transistor was presented to the world in 1948 when
Bell Labs decided to go public with its new device. In 1954, Bell
Labs constructed the first transistor-based computer. It was named
TRADIC (TRAnsistorized DIgital Computer). TRADIC was much
smaller and more efficient than vacuum tube computers. For exam-
ple, ENIAC required 1,000 square feet and caused power outages in
Philadelphia when it was turned on. TRADIC, on the other hand,
was roughly three cubic feet in size and ran on 100 watts of
electricity.

NOTE Before electronic computers became a feasible alternative,

heavy mathematical computation relied on human computers. Large
groups of people would be assembled to carry out massive numerical
algorithms. Each person would do a part of a computation and pass it
on to someone else. This accounts for the prevalance of logarithm
tables in mathematical references like the one published by the Chem-
ical Rubber Company (CRC). Slide rules and math tables were
standard fare before the rise of the digital calculator.

ASIDE
“After 45 minutes or so, we’ll see that the results are
obvious.”
— David M. Lee
I have heard Nobel laureates in physics, like Dave Lee,
complain that students who rely too heavily on calculators
lose their mathematical intuition. To an extent, Dave is cor-
rect. Before the dawn of calculators, errors were more com-
mon, and developing a feel for numeric techniques was a
useful way to help catch errors when they occurred.
During the Los Alamos project, a scientist named Dick
Feynman ran a massive human computer. He once mentioned
that the performance and accuracy of his group’s computa-
tions were often more a function of his ability to motivate
people. He would sometimes assemble people into teams
and have them compete against each other. Not only was
this a good idea from the standpoint of making things more
interesting, but it was also an effective technique for catching
discrepancies.

xv
Introduction

In 1958, the first integrated circuit was invented. The inventor was
a fellow named Jack Kilby, who was hanging out in the basement of
Texas Instruments one summer while everyone else was on vaca-
tion. A little over a decade later, in 1969, Intel came out with a 1
kilobit memory chip. After that, things really took off. By 1999, I
was working on a Windows NT 4.0 workstation (service pack 3) that
had 2GB of SDRAM memory.
The general trend you should be able to glean from the previous
discussion is that memory components have solved performance
requirements by getting smaller, faster, and cheaper. The hardware
people have been able to have their cake and eat it too. However,
the laws of physics place a limit on how small and how fast we can
actually make electronic components. Eventually, nature itself will
stand in the way of advancement. Heisenberg’s Uncertainty Princi-
ple, shown below, is what prevents us from building infinitely small
components.
D xD p ³ (h/4p )
For those who are math-phobic, I will use Heinsenberg’s own words
to describe what this equation means:
“The more precisely the position is determined, the less pre-
cisely the momentum is known in this instant, and vice versa.”
In other words, if you know exactly where a particle is, then you
will not be able to contain it because its momentum will be huge.
Think of this like trying to catch a tomato seed. Every time you try
to squeeze down and catch it, the seed shoots out of your hands and
flies across the dinner table into Uncle Don’s face.
Einstein’s General Theory of Relativity is what keeps us from
building infinitely fast components. With the exception of black
holes, the speed limit in this universe is 3x108 meters per second.
Eventually, these two physical limits are going to creep up on us.
When this happens, the hardware industry will have to either
make larger chips (in an effort to fit more transistors in a given area)
or use more efficient algorithms so that they can make better use of
existing space. My guess is that relying on better algorithms will be
the cheaper option. This is particularly true with regard to memory
management. Memory manipulation is so frequent and crucial to
performance that designing better memory management subsys-
tems will take center stage in the future. This will make the time
spent reading this book a good investment.

xvi
 Introduction

Impartial Analysis
In this book, I try very hard to offer memory management solutions
without taking sides. I have gone to great lengths to present an
unbiased discussion. This is important because it is extremely
tempting to champion a certain memory management algorithm
(especially if you invented it). There are some journal authors who
would have you believe that their new algorithm is a panacea to
cure the ills of the world. I do not have the ulterior motives of a col-
lege professor. I am here to offer you a set of tools and then let you
decide how best to use them. In this book, I will present you with
different techniques and try to point out the circumstances in which
they perform well.
The question “Which is the best memory management algo-
rithm?” is very similar in spirit to any of the following questions:
“Which operating system is the best?”
“Which programming language is the best?”
“Which data structure is the best?”
“Which type of screwdriver is the best?”
I can recall asking a program manager at Eaton Corp., John
Schindler, what the best operating system was. John was managing
at least a dozen different high-end platforms for Eaton, and I
thought he would know. I was expecting him to come right back
with a quick answer like: “Oh, OpenBSD is the best.” What actually
happened was something that surprised me. He looked at me for a
minute, as if the question was absurd. Then he smiled and said,
“Well, it really depends on what you’re going to use the machine for.
I use Solaris for networking, HP-UX for app servers, AIX to talk to
our mainframe, NT for mail, . . . ”
The truth is there is no “best” solution. Most solutions merely
offer certain trade-offs. In the end, the best tool to use will depend
upon the peculiarities of the problem you are trying to solve.
This is a central theme that appears throughout the domain of
computer science. Keep it in the back of your mind, like some sort
of Buddhist mantra:
“There is no best solution, Grasshopper, only trade-offs.”
For example, linked lists and arrays can both represent a linear set
of items. With a linked list, you get easy manipulation at the
expense of speed. Adding an element to a linked list is as easy as
modifying a couple of pointers. However, to find a given list

xvii
Introduction

element, you may have to traverse the entire list manually until you
find it. Conversely, with an array, you get access speed at the
expense of flexibility. Accessing an array element is as easy as add-
ing an integer to a base address, but adding and deleting array
elements requires a lot of costly shifting. If your code is not going to
do a lot of list modification, an array is the best choice. If your code
will routinely add and delete list members, a linked list is the better
choice. It all depends upon the context of the problem.

Audience
This book is directed toward professional developers and students
who are interested in discovering how memory is managed on pro-
duction systems. Specifically, engineers working on PC or
embedded operating systems may want to refresh their memory or
take a look at alternative approaches. If this is the case, then this
book will serve as a repository of algorithms and software compo-
nents that you can apply to your day-to-day issues.
Professionals who design and construct development tools will
also find this book useful. In general, development tools fall into the
class of online transaction processing (OLTP) programs. When it
comes to OLTP apps, pure speed is the name of the game. As such,
programming language tools, like compilers, often make use of
suballocators to speed up the performance of the code that manipu-
lates their symbol table.
With regard to compiling large software programs consisting of
millions of lines of code, this type of suballocator-based optimization
can mean the difference between waiting for a few minutes and
waiting for a few hours. Anyone who mucks around with
suballocators will find this book indispensable.
Software engineers who work with virtual machines will also be
interested in the topics that I cover. The Java virtual machine is
famous for its garbage collection facilities. In this book I explore
several automatic memory management techniques and also pro-
vide a couple of concrete garbage collection implementations in
C++.
Finally, this book also targets the curious. There is absolutely
nothing wrong with being curious. In fact, I would encourage it. You
may be an application developer who has used memory manage-
ment facilities countless times in the past without taking the time to

xviii
 Introduction

determine how they really work. You may also have nurtured an
interest that you have had to repress due to deadlines and other pri-
orities. This book will offer such engineers an opportunity to
indulge their desire to see what is going on under the hood.

Organization
This book is divided into six chapters. I will start from the ground
up and try to provide a comprehensive, but detailed, view of mem-
ory management fundamentals. Because of this, each chapter builds
on what has been presented in the previous one. Unless you are a
memory management expert, the best way to read this book is
straight through.

Chapter 1 – Memory Management Mechanisms

The first chapter presents a detailed look at the machinery that
allows memory management to take place. Almost every operating
system in production takes advantage of facilities that are provided
by the native processor. This is done primarily for speed, since
pushing repetitive bookkeeping down to the hardware benefits over-
all performance. There have been attempts by some engineers to
track and protect memory strictly outside of the hardware. But
speed is key to the hardware realm, and this fact always forces such
attempts off of the playing field. The end result is that understand-
ing how memory management is performed means taking a good
look at how memory hardware functions.

Chapter 2 – Memory Management Policies

Computer hardware provides the mechanism for managing memory,
but the policy decisions that control how this mechanism is applied
are dictated by the operating system and its system call interface to
user programs. In this chapter, the memory management compo-
nents provided by the operating system are analyzed and dissected.
This will necessarily involve taking a good, hard look at the inter-
nals of production operating systems like Linux and Windows.
In general, hardware always provides features that are ahead of
the software that uses it. For example, Intel’s Pentium provides four
distinct layers of memory protection. Yet, I could not find a single

xix
Introduction

operating system that took advantage of all four layers. All the sys-
tems that I examined use a vastly simplified two-layer scheme.

NOTE The relationship between hardware and software is analo-

gous to the relationship between mathematics and engineering.
Mathematics tends to be about 50 years ahead of engineering, which
means that it usually takes about 50 years for people to find ways to
apply the theorems and relationships that the mathematicians uncover.

Chapter 3 – High-Level Services

Above the hardware and the cocoon of code that is the operating
system are the user applications. Because they are insulated from
the inner workings of the operating system, applications have an
entirely different way to request, use, and free memory. The man-
ner in which a program utilizes memory is often dependent on the
language in which the program was written. This chapter looks at
memory management from the perspective of different program-
ming languages. This chapter also serves as a launch pad for the
next two chapters by presenting an overview of memory manage-
ment at the application level.

Chapter 4 – Manual Memory Management

In Chapter 4, a number of manual memory management algorithms
are presented in explicit detail. The algorithms are presented in the-
ory, implemented in C++, and then critiqued in terms of their
strengths and weaknesses. The chapter ends with suggestions for
improvements and a look at certain hybrid approaches.

Chapter 5 – Automatic Memory Management

In Chapter 5, a number of automatic memory management algo-
rithms are examined. The algorithms are presented in theory,
implemented in C++, and then critiqued in terms of their strengths
and weaknesses. A significant amount of effort is invested in mak-
ing this discussion easy to follow and keeping the reader focused on
key points. Two basic garbage collectors are provided and compared
to other, more advanced collection schemes.

xx
 Introduction

Chapter 6 – Miscellaneous Topics

This chapter covers a few special-purpose subjects that were diffi-
cult to fit into the previous five chapters. For example, I describe
how to effectively implement a suballocator in a compiler. I also take
a look at how memory management subsystems can be made to
provide dynamic algorithm support at run time via a microkernel
architecture.

Approach
When it comes to learning something complicated, like memory
management, I believe that the most effective way is to examine a
working subsystem. On the other hand, it is easy to become lost in
the details of a production memory manager. Contemporary mem-
ory managers, like the one in Linux, are responsible for keeping
track of literally hundreds of run-time quantities. Merely tracking
the subsystem’s execution path can make one dizzy. Hence, a bal-
ance has to be struck between offering example source code that is
high quality and also easy to understand. I think I have done a suffi-
cient job of keeping the learning threshold low without sacrificing
utility.

NOTE I am more than aware of several books where the author is

more interested in showing you how clever he is instead of actually try-
ing to teach a concept. When at all possible, I try to keep my examples
relatively simple and avoid confusing syntax. My goal is to instruct, not
to impress you so much that you stop reading.

In this book, I will follow a fairly standard three-step approach:

1. Theory
2. Practice
3. Analysis
I will start each topic by presenting a related background theory.
Afterwards, I will offer one or more source code illustrations and
then end each discussion with an analysis of trade-offs and alterna-
tives. I follow this methodology throughout the entire book.

xxi
Introduction

Typographical Conventions
Words and phrases will appear in italics in this book for two reasons:
n To place emphasis
n When defining a term
The courier font will be used to indicate that text is one of the
following:
n Source code
n An address in memory
n Console input/output
n A filename or extension
Numeric values appear throughout this book in a couple of different
formats. Hexadecimal values are indicated by either prefixing them
with “0x” or appending “H” to the end.
For example:
0xFF02
0FF02H

The C code that I include will use the former notation, and the
assembler code that I include will use the latter format.
Binary values are indicated by appending the letter “B” to the
end. For example:
0110111B

Prerequisites
“C makes it easy to shoot yourself in the foot; C++ makes it
harder, but when you do, it blows away your whole leg.”
— Bjarne Stroustrup

In this book, I have primarily used three different development

languages:
n 80x86 assembler
n C
n C++
For some examples, I had no other choice but to rely on assembly
language. There are some things, like handling processor

xxii
 Introduction

interrupts, that can only be fleshed out using assembler. This is one
reason why mid-level languages, like C, provide syntactic facilities
for inline assembly code. If you look at the Linux source code, you
will see a variety of inline assembly code snippets. If at all possible,
I wrapped my assembly code in C. However, you can’t always do
this.
Learning assembly language may seem like an odious task, but
there are several tangible and significant rewards. Assembly lan-
guage is just a mnemonic representation of machine instructions.
When you have a complete understanding of a processor’s assembly
language, including its special “privileged” instructions, you will
also have a fairly solid understanding of how the machine functions
and what its limitations are. In addition, given that compilers gener-
ate assembly code, or at least spit it out in a listing file, you will also
be privy to the inner workings of development tools.
In short, knowing assembly language is like learning Latin. It
may not seem immediately useful, but it is . . . just give it time.
I use C early in the book for small applications when I felt like I
could get away with it. Most of the larger source code examples in
this book, however, are written in C++. If you don’t know C or
C++, you should pick up one of the books mentioned in the “Refer-
ences” section at the end of the Introduction. After a few weeks of
cramming, you should be able to follow my source code examples.
I think C++ is an effective language for implementing memory
management algorithms because it offers a mixture of tools. With
C++, you can manipulate memory at a very low, bit-wise level and
invoke inline assembly code when needed. You can also create
high-level constructs using the object-oriented language features in
C++. Encapsulation, in particular, is a compiler-enforced language
feature that is crucial for maintaining large software projects.

NOTE At times, you may notice that I mix C libraries and conven-
tions into my C++ source code. I do this, most often, for reasons
related to performance. For example, I think that C’s printf() is
much more efficient than cout.

C++ is often viewed by engineers, including myself, as C with a

few object-oriented bells and whistles added on. Bjarne Stroustrup,
the inventor of C++, likes to think of it as a “better form of C.”
According to Stroustrup, the original C++ compiler (named Cfront,
as in “C front end”) started off as an elaborate preprocessor that
produced C code as output. This C code was then passed on to a

xxiii
Introduction

full-fledged C compiler. As time progressed, C++ went from being

a front end to a C compiler to having its own dedicated compiler.
Today, most software vendors sell C++ compilers with the implicit
understanding that you can also use them to write C code.
In general, C is about as close to assembly language as you can
get without losing the basic flow-control and stack-frame niceties
that accompany high-level languages. C was because Ken Thomp-
son got tired of writing assembly code. The first version of UNIX,
which ran on a DEC PDP-7 in the late 1960s, was written entirely in
assembler (and you thought that Mike Podanoffsky had it tough).
Ken solved his assembly language problems by creating a variation
of BCPL, which he called B. The name of the programming lan-
guage was then changed to “C” by Dennis Ritchie, after some
overhauling. Two Bell Labs researchers, Brian Kernighan and Den-
nis Ritchie, ended up playing vital roles in the evolution of the
language. In fact, the older form of C’s syntax is known as
Kernighan and Ritchie C (or just K&R C).
C and C++ are both used to implement operating systems.
Linux, for example, is written entirely in C. Although C is still the
dominant system language for historical reasons, C++ is slowly
beginning to creep into the source code bases of at least a couple
commercial operating systems. Microsoft’s Windows operating sys-
tem has chunks of its kernel written in C++. One might speculate
that this trend can be directly linked to the rapidly increasing com-
plexity of operating systems.

Companion Files
Software engineering is like baseball. The only way you will ever
acquire any degree of skill is to practice and scrimmage whenever
you get the chance. To this end, I have included the source code for
most of the examples in this book in a downloadable file available at
www.wordware.com/memory.
Dick Feynman, who was awarded the Nobel Prize in physics in
1965, believed that the key to discovery and insight was playful
experimentation. Dick was the kind of guy who followed his own
advice. In his biography, Surely You’re Joking, Mr. Feynman, Dick
recounts how spinning plates in a dining hall at Cornell led to his-
toric work in quantum mechanics. By testing a variety of new ideas
and comparing the results to your predictions, you force yourself to

xxiv
 Introduction

gain a better understanding of how things work. This approach also

gives you the hands-on experience necessary to nurture a sense of
intuition.
It is in this spirit that I provide this book’s source code in the
downloadable files. By all means, modify it, hack it, and play with it.
Try new things and see where they lead you. Make predictions and
see if empirical results support your predictions. If the results don’t,
then try to determine why and construct alternative explanations.
Test those explanations. Add new functionality and see how it
affects things. Take away components and see what happens. Bet a
large sum of money with a friend to see who can implement the best
improvement. But above all, have fun.

References
Brey, Barry. The Intel Microprocessors: 8086/8088, 80186, 80286,
80386, 80486, Pentium, Pentium Pro, and Pentium II. 2000,
Prentice Hall, ISBN: 0-13-995408-2.
This is a fairly recent book and should take care of any ques-
tions you may have. Barry has been writing about Intel chips
since the first one came out.
Kernighan, Brian and Dennis Ritchie. The C Programming Lan-
guage. 1988, Prentice Hall, ISBN: 0131103628.
This is a terse, but well-read introduction to C by the founding
fathers of the language.
Reid, T. R. The Chip: How Two Americans Invented the Microchip
and Launched a Revolution. 2001, Random House, ISBN:
0375758283.
Schildt, Herbert. C++ From the Ground Up. 1998, Osborne
McGraw-Hill, ISBN: 0078824052.
If you have never programmed in C/C++, read this book. It is
a gentle introduction written by an author who knows how to
explain complicated material. Herb starts by teaching you C and
then slowly introducing the object-oriented features of C++.
Stroustrup, Bjarne and Margaret Ellis. The Annotated C++ Refer-
ence. 1990, Addison-Wesley, ISBN: 0201514591.
Once you have read Schildt’s book, you can use this text to fill
in the gaps. This book is exactly what it says it is — a reference
— and it is a good one.

xxv
Introduction

Stroustrup, Bjarne. The Design and Evolution of C++. 1994,

Addison-Wesley Pub. Co., ISBN: 0201543303.
This is an historical recount of C++’s creation by the man
who invented the language. The discussion is naturally very
technical and compiler writers will probably be able to appreciate
this book the most. This is not for the beginner.

Warning
In this book I provide some rather intricate, and potentially danger-
ous, source code examples. This is what happens when you go
where you are not particularly supposed to be. I recommend that
you use an expendable test machine to serve as a laboratory. Also,
you might want to consider closing all unnecessary applications
before experimenting. If an application dies in the middle of an
access to disk, you could be faced with a corrupt file system.
If you keep valuable data on the machine you are going to use, I
suggest you implement a disaster recovery plan. During the writing
of this book’s manuscript, I made a point to perform daily incremen-
tal backups and complete weekly backups of my hard drive. I also
had a secondary machine that mirrored by primary box. Large cor-
porations, like banks and insurance companies, have truly extensive
emergency plans. I toured a production site in Cleveland that had
two diesel fuel generators and a thousand gallons of gas to provide
backup power.
Neither the publisher nor author accept any responsibility for any
damage that may occur as a result of the information contained
within this book. As Stan Lee might say, “With great power comes
great responsibility.”

xxvi
Author Information
Bill Blunden has been obsessed with systems software since his
first exposure to the DOS debug utility in 1983. His single-minded
pursuit to discover what actually goes on under the hood led him to
program the 8259 interrupt controller and become an honorable
member of the triple-fault club. After obtaining a BA in mathemati-
cal physics and an MS in operations research, Bill was unleashed
upon the workplace. It was at an insurance company in the beautiful
city of Cleveland, plying his skills as an actuary, that Bill got into his
first fist fight with a cranky IBM mainframe. Bloody but not beaten,
Bill decided that groking software beat crunching numbers. This led
him to a major ERP player in the midwest, where he developed
CASE tools in Java, wrestled with COBOL middleware, and was
assailed by various Control Data veterans. Having a quad-processor
machine with 2GB of RAM at his disposal, Bill was hard pressed to
find any sort of reason to abandon his ivory tower. Nevertheless, the
birth of his nephew forced him to make a pilgrimage out west to Sil-
icon Valley. Currently on the peninsula, Bill survives rolling power
blackouts and earthquakes, and is slowly recovering from his initial
bout with COBOL.

xxvii
Chapter 1

Memory Management
Mechanisms
“Everyone has a photographic memory. Some people just don’t
have film.”
— Mel Brooks

NOTE In the text of this book, italics are used to define or

emphasize a term. The Courier font is used to denote code, memory
addresses, input/output, and filenames. For more information, see the
section titled “Typographical Conventions” in the Introduction.

Mechanism Versus Policy

Accessing and manipulating memory involves a lot of accounting
work. Measures have to be taken to ensure that memory being
accessed is valid and that it corresponds to actual physical storage.
If memory protection mechanisms are in place, checks will also need
to be performed by the processor to ensure that an executing task
does not access memory locations that it should not. Memory pro-
tection is the type of service that multiuser operating systems are
built upon. If virtual memory is being used, a significant amount of
bookkeeping will need to be maintained in order to track which disk
sectors belong to which task. It is more effort than you think, and all
the steps must be completed flawlessly.

NOTE On the Intel platform, if the memory subsystem’s data struc-

tures are set up incorrectly, the processor will perform what is known
as a triple fault. A double fault occurs on Intel hardware when an
exception occurs while the processor is already trying to handle an
exception. A triple fault occurs when the double-fault handler fails and
the machine is placed into the SHUTDOWN cycle. Typically, an Intel
machine will reset when it encounters this type of problem.

1
2 Chapter 1

For the sake of execution speed, processor manufacturers give their

chips the capacity to carry out advanced memory management
chores. This allows operating system vendors to effectively push
most of the tedious, repetitive work down to the processor where
the various error checks can be performed relatively quickly. This
also has the side effect of anchoring the operating system vendor to
the hardware platform, to an extent.
The performance gains, however, are well worth the lost porta-
bility. If an operating system were completely responsible for
implementing features like paging and segmentation, it would be
noticeably slower than one that took advantage of the processor’s
built-in functionality. Imagine trying to play a graphics-intensive,
real-time game like Quake 3 on an operating system that manually
protected memory; the game would just not be playable.

NOTE You might be asking if I can offer a quantitative measure of

how much slower an operating system would be. I will admit I have
been doing a little arm waving. According to a 1993 paper by Wahbe,
Lucco, et al. (see the “References” section), they were able to isolate
modules of code in an application using a technique they labeled as
sandboxing. This technique incurred a 4% increase in execution speed.
You can imagine what would happen if virtual memory and access
privilege schemes were added to such a mechanism.

ASIDE
An arm-waving explanation is a proposition that has not been
established using precise mathematical statements. Mathe-
matical statements have the benefit of being completely un-
ambiguous: They are either true or false. An arm-waving
explanation tends to eschew logical rigor entirely in favor of
arguments that appeal to intuition. Such reasoning is at best
dubious, not only because intuition can often be incorrect, but
also because intuitive arguments are ambiguous. For example,
people who argue that the world is flat tend to rely on arm-
waving explanations.

NOTE Back when Dave Cutler’s brainchild, Windows NT, came out,
there was a lot of attention given to the operating system’s Hardware
Abstraction Layer (HAL). The idea was that the majority of the operat-
ing system could be insulated from the hardware that it ran on by a
layer of code located in the basement. This was instituted to help
counter the hardware dependency issue that I mentioned a minute
ago. To Dave’s credit, NT actually did run on a couple of traditionally
UNIX-oriented hardware platforms. This included Digital’s Alpha pro-
cessor and the MIPS RISC processor. The problem was that Microsoft
couldn’t get a number of its higher-level technologies, like DCOM, to
 Memory Management Mechanisms 3

run on anything but Intel. So much for an object technology based on

Chapter 1
a binary standard!

The solution that favors speed always wins. I was told by a former
Control Data engineer that when Seymour Cray was designing the
6600, he happened upon a new chip that was quicker than the one
he was currently using. The problem was that it made occasional
computational errors. Seymour implemented a few slick work-
arounds and went with the new chip. The execs wanted to stay out
of Seymour’s way and not disturb the maestro, as Seymour was
probably the most valuable employee Control Data had. Unfortu-
nately, they also had warehouses full of the original chips. They
couldn’t just throw out the old chips; they had to find a use for them.
This problem gave birth to the CDC 3300, a slower and less expen-
sive version of the 6600.
My point: Seymour went for the faster chip, even though it was
less reliable.
Speed rules.
The result of this tendency is that every commercial operating
system in existence has its memory management services firmly
rooted in data structures and protocols dictated by the hardware.
Processors provide a collection of primitives for manipulating mem-
ory. They constitute the mechanism side of the equation. It is up to
the operating system to decide if it will even use a processor’s
memory management mechanisms and, if so, how it will use them.
Operating systems constitute the policy side of the equation.
In this chapter, I will examine computer hardware in terms of
how it offers a mechanism to access and manipulate memory.

Memory Hierarchy
When someone uses the term “memory,” they are typically refer-
ring to the data storage provided by dedicated chips located on the
motherboard. The storage these chips provide is often referred to
as Random Access Memory (RAM), main memory, and primary stor-
age. Back in the iron age, when mainframes walked the earth, it was
called the core. The storage provided by these chips is volatile,
which is to say that data in the chips is lost when the power is
switched off.
There are various types of RAM:
n DRAM
n SDRAM
n SRAM
4 Chapter 1

n VRAM
Dynamic RAM (DRAM) has to be recharged thousands of times
each second. Synchronous DRAM (SDRAM) is refreshed at the
clock speed at which the processor runs the most efficiently. Static
RAM (SRAM) does not need to be refreshed like DRAM, and this
makes it much faster. Unfortunately, SRAM is also much more
expensive than DRAM and is used sparingly. SRAM tends to be
used in processor caches and DRAM tends to be used for wholesale
memory. Finally, there’s Video RAM (VRAM), which is a region of
memory used by video hardware. In the next chapter, there is an
example that demonstrates how to produce screen messages by
manipulating VRAM.
Recent advances in technology and special optimizations imple-
mented by certain manufacturers have led to a number of additional
acronyms. Here are a couple of them:
n DDR SDRAM
n RDRAM
n ESDRAM
DDR SDRAM stands for Double Data Rate Synchronous Dynamic
Random Access Memory. With DDR SDRAM, data is read on both
the rising and the falling of the system clock tick, basically doubling
the bandwidth normally available. RDRAM is short for Rambus
DRAM, a high-performance version of DRAM sold by Rambus that
can transfer data at 800 MHz. Enhanced Synchronous DRAM
(ESDRAM), manufactured by Enhanced Memory Systems, provides
a way to replace SRAM with cheaper SDRAM.
A bit is a single binary digit (i.e., a 1 or a 0). A bit in a RAM chip
is basically a cell structure that is made up of, depending on the type
of RAM, a certain configuration of transistors and capacitors. Each
cell is a digital switch that can either be on or off (i.e., 1 or 0). These
cells are grouped into 8-bit units call bytes. The byte is the funda-
mental unit for measuring the amount of memory provided by a
storage device. In the early years, hardware vendors used to imple-
ment different byte sizes. One vendor would use a 6-bit byte and
another would use a 16-bit byte. The de facto standard that every-
one seems to abide by today, however, is the 8-bit byte.
There is a whole set of byte-based metrics to specify the size of a
memory region:
1 byte = 8 bits
1 word = 2 bytes
1 double word = 4 bytes
 Memory Management Mechanisms 5

1 quad word = 8 bytes

Chapter 1
1 octal word = 8 bytes
1 paragraph = 16 bytes
1 kilobyte (KB) = 1,024 bytes
1 megabyte (MB) = 1,024KB = 1,048,576 bytes
1 gigabyte (GB) = 1,024MB = 1,073,741,824 bytes
1 terabyte (TB) = 1,024GB = 1,099,511,627,776 bytes
1 petabyte (PB) = 1,024TB = 1,125,899,906,842,624 bytes

NOTE In the 1980s, having a megabyte of DRAM was a big deal.

Kids used to bug their parents for 16KB memory upgrades so their
Atari 400s could play larger games. At the time, having only a mega-
byte wasn’t a significant problem because engineers tended to
program in assembly code and build very small programs. In fact, this
1981 quote is often attributed to Bill Gates: “640K ought to be enough
for anybody.”

Today, most development machines have at least 128MB of DRAM.

In 2002, having 256MB seems to be the norm. Ten years from now,
a gigabyte might be the standard amount of DRAM (if we are still
using DRAM). Hopefully, someone will not quote me.
RAM is not the only place to store data, and this is what leads us
to the memory hierarchy. The range of different places that can be
used to store information can be ordered according to their proxim-
ity to the processor. This ordering produces the following hierarchy:
1. Registers
2. Cache
3. RAM
4. Disk storage
The primary distinction between these storage areas is their mem-
ory latency, or lag time. Storage closer to the processor takes less
time to access than storage that is further away. The latency experi-
enced in accessing data on a hard drive is much greater than the
latency that occurs when the processor accesses memory in its
cache. For example, DRAM latency tends to be measured in nano-
seconds. Disk drive latency, however, tends to be measured in
milliseconds! (See Figure 1.1 on the following page.)
Registers are small storage spaces that are located within the
processor itself. Registers are a processor’s favorite workspace.
Most of the processor’s day-to-day work is performed on data in the
registers. Moving data from one register to another is the single
most expedient way to move data.
6 Chapter 1

Figure 1.1

Software engineers designing compilers will jump through all

sorts of hoops just to keep variables and constants in the registers.
Having a large number of registers allows more of a program’s state
to be stored within the processor itself and cut down on memory
latency. The MIPS64 processor has 32, 64-bit, general-purpose reg-
isters for this very reason. The Itanium, Intel’s next generation
64-bit chip, goes a step further and has literally hundreds of
registers.
The Intel Pentium processor has a varied set of registers (see
Figure 1.2). There are six, 16-bit, segment registers (CS, DS, ES,
FS, GS, SS). There are eight, 32-bit, general-purpose registers
(EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP). There is also a 32-bit
error flag register (EFLAGS) to signal problems and a 32-bit
instruction pointer (EIP).
Advanced memory management functions are facilitated by four
system registers (GDTR, LDTR, IDTR, TR) and five mode control
registers (CR0, CR1, CR2, CR3, CR4). The usage of these registers
will be explained in the next few sections.

NOTE It is interesting to note how the Pentium’s collection of regis-

ters has been constrained by historical forces. The design requirement
demanding backward compatibility has resulted in the Pentium having
only a few more registers than the 8086.

A cache provides temporary storage that can be accessed quicker

than DRAM. By placing computationally intensive portions of a pro-
gram in the cache, the processor can avoid the overhead of having
 Memory Management Mechanisms 7

Chapter 1
Figure 1.2

to continually access DRAM. The savings can be dramatic. There

are different types of caches. An L1 cache is a storage space that is
located on the processor itself. An L2 cache is typically an SRAM
chip outside of the processor (for example, the Intel Pentium 4
ships with a 256 or 512KB L2 Advanced Transfer Cache).

NOTE If you are attempting to optimize code that executes in the

cache, you should avoid unnecessary function calls. A call to a distant
function requires the processor to execute code that lies outside the
cache. This causes the cache to reload. This is one reason why certain
C compilers offer you the option of generating inline functions. The
other side of the coin is that a program that uses inline functions will
be much larger than one that does not. The size-versus-speed
trade-off is a balancing act that rears its head all over computer
science.

Disk storage is the option of last resort. Traditionally, disk space

has been used to create virtual memory. Virtual memory is memory
that is simulated by using disk space. In other words, portions of
memory, normally stored in DRAM, are written to disk so that the
amount of memory the processor can access is greater than the
actual amount of physical memory. For example, if you have 10MB
of DRAM and you use 2MB of disk space to simulate memory, the
processor can then access 12MB of virtual memory.
8 Chapter 1

NOTE A recurring point that I will make throughout this book is the
high cost of disk input/output. As I mentioned previously, the latency
for accessing disk storage is on the order of milliseconds. This is a long
time from the perspective of a processor. The situation is analogous to
making a pizza run from a remote cabin in North Dakota. If you are
lucky, you have a frozen pizza in your freezer/cache and it will only
take 30 minutes to heat up. If you are not lucky, you will have to call
the pizza delivery guy (i.e., access the data from disk storage) and wait
for five hours as he makes the 150-mile trek to your cabin.

Using virtual memory is like making a deal with the devil. Sure, you
will get lots of extra memory, but you will pay an awful cost in terms
of performance. Disk I/O involves a whole series of mandatory
actions, some of which are mechanical. It is estimated that paging
on Windows accounts for roughly 10% of execution time. Managing
virtual memory requires a lot of bookkeeping on the part of the pro-
cessor. I will discuss the precise nature of this bookkeeping in a
later section.

ASIDE
I worked at an ERP company where one of the VPs used to
fine engineers for performing superfluous disk I/O. During
code reviews, he would grep through source code looking for
the fopen() and fread() standard library functions. We
were taught the basic lesson that you cached everything you
possibly could in memory and only moved to disk storage
when you absolutely had no other alternative (and even then
you needed permission). To the VP’s credit, the company’s
three-tier middleware suite was the fastest in the industry.

Disk storage has always been cheaper than RAM. Back in the 1960s
when 8KB of RAM was a big investment, using the disk to create
virtual memory probably made sense. Today, however, the cost dis-
crepancy between DRAM and disk drives is not as significant as it
was back then. Buying a machine with 512MB of SDRAM is not
unheard of. It could be that virtual memory will become a complete
relic or implemented as some sort of emergency safeguard.
 Memory Management Mechanisms 9

Address Lines and Buses

Chapter 1
Each byte in DRAM is assigned a unique numeric identifier called
an address, just like houses on a street. An address is an integer
value. The first byte in memory is assigned an address of zero. The
region of memory near address zero is known as the bottom of mem-
ory, or low memory. The region of memory near the final byte is
known as high memory. The number of physical (i.e., DRAM) bytes
that a processor is capable of addressing is known as the processor’s
physical address space. (See Figure 1.3.)

Figure 1.3

The physical address space of a processor specifies the potential

number of bytes that can be addressed, not the actual number of
physical bytes present. People normally don’t want to spend the
money necessary to populate the entire physical address space with
DRAM chips. Buying 4GB of DRAM is still usually reserved for
high-end enterprise servers.
The physical address space of a processor is determined by the
number of address lines that it has. Address lines are a set of wires
connecting the processor to its DRAM chips. Each address line
specifies a single bit in the address of a given byte. For example, the
Intel Pentium has 32 address lines. This means that each byte is
assigned a 32-bit address so that its address space consists of 232
addressable bytes (4GB). The 8088 had 20 address lines, so it was
capable of addressing 220, or 1,048,576, bytes.

NOTE If virtual memory is enabled on the Pentium 4, there is a way

to enable four additional address lines using what is known as Physical
Address Extension (PAE). This allows the Pentium processor’s physical
address space to be defined by 36 address lines, which translates into
an address space of 236 bytes (64GB).
10 Chapter 1

To access and update physical memory, the processor uses a control

bus and a data bus. A bus is a collection of related wires that connect
the processor to a hardware subsystem. The control bus is used to
indicate if the processor wants to read from memory or write to
memory. The data bus is used to ferry data back and forth between
the processor and memory. (See Figure 1.4.)

Figure 1.4

When the processor reads from memory, the following steps are
performed:
1. The processor places the address of the byte to be read on the
address lines.
2. The processor sends the read signal on the control bus.
3. The DRAM chip(s) return the byte specified on the data bus.
When the processor writes to memory, the following steps are
performed:
1. The processor places the address of the byte to be written on
the address lines.
2. The processor sends the write signal on the control bus.
3. The processor sends the byte to be written to memory on the
data bus.
This description is somewhat of an oversimplification. For example,
the Pentium processor reads and writes data 4 bytes at a time. This
is one reason why the Pentium is called a 32-bit chip. The processor
will refer to its 32-bit payload using the address of the first byte
(i.e., the byte with the lowest address). Nevertheless, I think the
general operation is clear.
 Memory Management Mechanisms 11

Intel Pentium Architecture

Chapter 1
You have seen how a processor reads and writes bytes to memory.
However, most processors also support two advanced memory man-
agement mechanisms: segmentation and paging.
Segmentation is instituted by breaking up a computer’s address
space into specific regions, known as segments. Using segmentation
is a way to isolate areas of memory so that programs cannot inter-
fere with one another. Segmentation affords what is known as
memory protection. It is possible to institute memory segmentation
without protection, but there are really no advantages to such a
scheme.
Under a segmentation scheme that enforces memory protection,
each application is assigned at least one segment. Large applications
often have several segments. In addition, the operating system will
also have its own custom set of segments. Segments are assigned a
specific set of access writes so that policies can be created with
regard to who can update what. Typically, the operating system code
segments will execute with the highest privilege and applications
will be loaded into segments with less authority.

Figure 1.5

Paging is a way to implement virtual memory. The physical memory

provided by DRAM and disk storage, which is allocated to simulate
DRAM, are merged together into one big amorphous collection of
bytes. The total number of bytes that a processor is capable of
addressing, if paging is enabled, is known as its virtual address
space.
12 Chapter 1

The catch to all this is that the address of a byte in this artifi-
cial/virtual address space is no longer the same as the address that
the processor places on the address bus. This means that transla-
tion data structures and code will have to be established in order to
map a byte in the virtual address space to a physical byte (regard-
less of whether that byte happens to be in DRAM or on disk).
When the necessary paging constructs have been activated, the
virtual memory space is divided into smaller regions called pages. If
the operating system decides that it is running low on physical
memory, it will take pages that are currently stored in physical
memory and write them to disk. If segmentation is being used,
bookkeeping will have to be performed in order to match a given
page of memory with the segment that owns it. All of the account-
ing work is done in close conjunction with the processor so that the
performance hit associated with disk I/O can be kept to a minimum.

Figure 1.6

NOTE When pages of data are stored in physical memory (i.e.,

DRAM), they are placed in page-sized slots that are known as page
frames. In addition to keeping track of individual pages, most operat-
ing systems also monitor page frame usage. The number of page
frames is usually much smaller than the number of pages, so it is in
the best interest of the operating system to carefully manage this pre-
cious commodity.

NOTE It is possible to use paging without using disk space. But in

this case, paging transforms into a hybrid form of segmentation that
deals with 4KB regions of memory.
 Memory Management Mechanisms 13

Because Intel’s Pentium class of processors is easily accessible, I

Chapter 1
decided to use the Pentium to help illustrate segmentation and pag-
ing. I would love to demonstrate theory with a MIPS64 processor,
but I can’t afford an SGI server (sigh). Being inexpensive is one of
the primary reasons for Intel’s continued success. Hackers, like me,
who couldn’t afford an Apple IIe back in the 1980s were left
scrounging for second-hand Intel boxes. There were thousands of
people who had to make this kind of financial decision. So, in a
sense, the proliferation of Intel into the workplace was somewhat of
a grass roots movement.
The Pentium class of processors is descended from a long line of
popular CPUs:
CPU Release Date Physical Address Space
8086 1978 1MB
8088 1979 1MB
80286 1982 16MB
80386 1985 4GB
80486 1989 4GB
Pentium 1993 4GB
Pentium Pro 1995 64GB
Pentium II 1997 64GB
Pentium III 1999 64GB
Pentium 4 2000 64GB

NOTE When the IBM PC came out in 1981, it shipped with a 4.77
MHz 8088. Without a doubt, mainframe developers were overjoyed.
This was because the PC gave them a place of their own. In those
days, the standard dummy terminals didn’t do anything more than
shuttle a data buffer back and forth to a mainframe. In addition, an
engineer had little or no control over when, or how, his code would be
run. The waiting could be agonizing. Tom Petty was right. Bribing a
sysop with pizza could occasionally speed things up, but the full court
grovel got tiring after a while. With an IBM PC, an engineer finally had
a build machine that was open all night with no waiting.

ASIDE
I know one CDC engineer, in particular, who ported a FOR-
TRAN ’77 compiler to a PC in 1982 for this very reason. His
supervisor would walk over and say: “Why do you want to run
on that little three-wheeler instead of the production ma-
chine?” His answer: “Because it is mine, damn it.” This one
statement probably summarizes the mindset that made PCs
wildly successful.
14 Chapter 1

In an attempt to keep their old customers, Intel has gone to great

lengths to make their 32-bit processors backward compatible with
the previous 16-bit models. As testimony to Intel’s success, I can
boot my laptop with a DOS 6.22 boot disk and run most of my old
DOS applications (including Doom and Duke Nukem).
A product of the requirement for backward compatibility is that
the Pentium chip operates in a number of different modes. Each
mode dictates how the processor will interpret machine instructions
and how it can access memory. Specifically, the Pentium is capable
of operating in four modes:
n Real mode
n Protected mode
n System management mode (SMM)
n Virtual 8086 mode
System management mode and virtual 8086 mode are both special-
purpose modes of operation that are only used under special cir-
cumstances. I will focus primarily on the first two modes of
operation: real mode and protected mode. In addition, I will investi-
gate how each of these modes support segmentation and paging.
Having the processor operate in different modes is not a feature
limited to the Intel platform. The MIPS64 processor, for example,
also operates in four modes:
n Kernel mode
n User mode
n Debug mode
n Supervisor mode

Real Mode Operation

The first IBM PC ran strictly in real mode. Furthermore, all 32-bit
Intel computers also start in real mode when they are booted. This
sort of provides a least common denominator behavior that back-
ward compatibility depends upon.
Real mode operating systems tend to be very small (i.e., less
than 128KB) because they rely on the BIOS to provide an interface
to the hardware. This allows them to easily fit on a 1.44MB floppy
diskette. Virus protection rescue disks rely on this fact, as do sys-
tem repair disks. I have also bought drive partitioning software that
can be run from a boot disk.
In real mode, the general-purpose registers we saw earlier in
Figure 1.2 are truncated into 16-bit registers, as are the error flag
 Memory Management Mechanisms 15

and instruction pointer registers. The real mode register setup is

Chapter 1
displayed in Figure 1.7.

Figure 1.7

As you can see, the “E” prefix has been removed from the regis-
ter names. In addition, each of the 16-bit general registers, AX, CX,
DX, and EX, can be manipulated in terms of two 8-bit registers. For
example, the AX register can be seen as the combination of the AH
and AL registers. The AH register refers to the high byte in AX,
and the AL register refers to the low byte in AX.

NOTE The memory and mode registers shown in Figure 1.2 are still
visible in real mode. They still exist if the processor is a 32-bit class
CPU but they have no significance or use in real mode. The only
exception to this rule is if you are trying to switch to protected mode.

A machine in real mode can address 1MB of DRAM. This implies

that only 20 address lines are used in real mode. The address of a
byte in memory, for a processor real mode, is formed by adding an
offset address to a segment address. The result of the sum is always
a 20-bit value (remember this fact; it is important), which confirms
our suspicion that there are 20 address lines.
The address formed by the sum of the segment and offset
addresses corresponds directly to the value that is placed on the
processor’s address lines. Now you can get a better idea of why
they call it “real” mode. The address of a byte in real mode maps
directly to a “real” byte in physical memory.
16 Chapter 1

An address is denoted, in Intel assembly language, by a seg-

ment:offset pair. For example, if a byte is located in segment
0x8200 and is situated at an offset of 0x0100, the address of this
byte is specified as:
0x8200:0x0100

Sometimes, for reasons that I will explain later, this is also written
as:
0x8200[0]:0x0100

The real mode address resolution process is displayed in Figure 1.8.

Figure 1.8

Segment addresses denote a particular memory segment and are

always stored in one of the 16-bit segment registers. Specifically, a
segment address specifies the base address, the lowest address, of a
memory segment. Each segment register has a particular use:
Register Use
CS Segment address of code currently being executed
SS Segment address of stack
DS Data segment address
ES Extra segment address (usually data)
FS Extra segment address (usually data)
GS Extra segment address (usually data)

NOTE The fact that there are six segment registers means that at
any time, only six segments of memory can be manipulated. A pro-
gram can have more than six segments, but only six can be accessible
at any one point in time.
 Another Random Document on
Scribd Without Any Related Topics
After he had been sitting there a couple of hours, a poor, destitute-
looking girl came to him, saying: “My mother lives not far from here.
I will take you to her.” On going home with the girl he learned that
her mother was his own sister and that she was therefore his niece.
He told his sister about the visit of the two women, about setting out
to shoot the eagle and being robbed on the road of everything but
his bow and arrows, and, lastly, about becoming decrepit and aged-
looking from the effects of the hickory bark thrust down his
backbone. His sister and her daughter were very poor. They had no
meat. As they were talking, a robin perched on the edge of the
smoke-hole. Hatʻhondas drew his bow with great difficulty and shot
an arrow which killed the bird. His sister cut it into small pieces and,
bruising them, made some soup, which in a measure strengthened
her brother. The next day a partridge came in like manner and he
killed that, too; and then a turkey, so they had provision enough.
Many days later his sister drew the bark from her brother’s back and
he became well again.

As he sat by the door one day he heard a great shouting and tumult,
and asked what it meant. They told him that it was the sounds made
by those who had assembled to shoot the eagle, and [142]pointed
out the great hickory tree, the top of which could be seen above the
forest, seemingly not more than 200 or 300 rods away.

The next day, on looking toward the tree, he could see that some
arrows came very near the eagle, some not so near, and others far
away from it. At last he said, “I must shoot an arrow at that eagle.”
“Oh!” said the sister, “you can not hit it from here.” But he would
have his own way, and going outside of the lodge with his bow and
arrow, he said to his sister’s daughter: “Go out into the crowd. When
I shoot the arrow and the bird falls to the ground run and bring it
here with the arrow sticking in it, and let no one take it from you.”
The girl went. Her uncle shot, and his arrow, flying through the air,
struck the eagle. When she grasped the bird after it had fallen to the
ground a man pushed her aside, and snatching the bird from her
disappeared in the crowd. She cried out, but no one heeded her.
Now, the crowd gathered at a mound, a short distance from the
tree. On this mound the great witch woman was sitting with her
friends to witness the shooting. The people stood in a circle. The
stranger came up with the eagle and claimed her youngest daughter,
who, insisting that he was not the right man, refused to marry him;
but the old woman said her promise must be kept, and had the
marriage proclaimed.

When, in the evening, the young wife would not remove her
designated husband’s clothing, the old woman did so. On taking off
the moccasins, and throwing them, tied together, over a crossbar
near the couch, they became owls, so wretchedly weak that they
were barely able to hold on to their perch; and so with the panther,
the wildcats, and the otter; they seemed scarcely alive.

The young woman would not go near her designated husband, but,
rolling herself up in a bearskin, slept apart. The next morning the
mother-in-law, addressing her intended son-in-law, said: “What can
you do for me [in thaumaturgy]?” He opened his pouch, from out of
which came the girls, who were barely able to bring a coal of fire,
and the pigeons, nearly lifeless. He smoked, and cast spittle on a
deerskin which was spread before him, and spittle it remained. Again
he tried, but with the same result. Then the mother-in-law, growing
angry, went away in disgust and chagrin.

The evening after Hatʻhondas was robbed the sky was red, and his
uncle at home knew that his nephew was in great trouble—that his
life was in danger. He sat down by the fire, throwing ashes on his
head, and wept, saying, “Oh! nephew, I shall mourn for you ten
summers.” But now the sky was not so red, and the old man knew
that his nephew had gained some relief.

The second night the young woman slept apart from her designated
husband. [143]

The next day Hatʻhondas’s niece, the poor woman’s daughter, said,
“I will visit the great witch woman, for she is a friend of mine.” When
the girl went to the lodge, the great woman was glad to see her. She
heard all the news of the marriage and that the young woman would
not go near her designated husband. On reaching home she told her
mother all she had heard. The next day very early, while the strange
man was still asleep, Hatʻhondas’s sister went into the great witch
woman’s lodge and, taking the panther-skin coat with the rest of the
garments and having thrust the piece of hickory bark into the back
of the sleeping husband, hurried home.

Hatʻhondas now had his whole outfit. Putting on his garments and
taking his bow and arrows he went to the lodge of the great witch
woman. When the daughter saw him coming, she could scarcely
retain herself for joy, crying out, “That is the man! That is the man!”

It was now almost noon, and the designated husband had not
appeared. On looking for him they found him on the couch all
doubled up, old and miserable, and coughing terribly.

As the arrow which was still sticking in the eagle was unlike his
arrows but just like those which were in the quiver of Hatʻhondas,
the people were convinced that the old man was a deceiver, so they
threw him out without pity.

Hatʻhondas was now married to the young woman and her mother
proclaimed to all the people, “My youngest daughter is now
married.” In the evening, when the young wife pulled off her
husband’s moccasins and threw them on the crossbeam, they
became a pair of fine owls with great eyes, and hooted; as soon as
the panther-skin coat touched the beam it became a large panther;
the leggings became two wildcats; and the cap an otter.

The next evening the mother-in-law asked her son-in-law, “What can
you do for me?” and spread a deerskin in front of him. As he opened
his pouch the two girls jumped out of it, followed by the two
pigeons. The girls, running nimbly to the fire, brought coals for
lighting the pipe. The pigeons, perching on the pipe as he put it into
his mouth, rustled their wings and cooed. As often as he spat the
spittle fell on the skin in a shower of wampum beads.

The next day he went hunting and killed so many deer, bear, and elk
that all the people had enough, and he sent a great supply to his
sister.

After they had enjoyed life a while, he said, “Now, I must go to my

uncle.” His sister prepared provisions for the journey. She would
shake all the flesh of a deer until it became small as the end of her
little finger, continuing this process until she had in a small pouch
venison enough to fill a lodge. On the way when they wanted [144]to
eat venison all they had to do was to strike a very small portion,
when the meat would resume its natural size. So they traveled till
they came to the old uncle’s lodge.

While his nephew had been away, animals had tormented him by
coming to his door while he was sitting near the fire mourning for
his nephew. He would hear a voice at the door cry, “Quick, Uncle! I
have returned,” but on opening the door-flap he would find merely a
fox, rabbit, or some other creature.

Now, to make sure, he cut a hole in the skin door-flap saying, “Put
your hand through the hole, if you are my nephew.” This being
done, he tied a strong bark string around the wrist and fastened the
other end to the pole at the fireplace; then, seizing the corn-
pounder, he opened the door carefully, intending to strike the
intruder. On discovering, however, that it was really his nephew, he
rejoiced and cried out: “Oh! you have come at last with your wife.
Wait, until I clean up a little.” Soon he let them in. The venison was
increased in quantity again by striking it against the ground, and
there was more than enough to fill the lodge, so they had to build a
new lodge in which to store it.

They lived on together happily. This is the story of Hatʻhondas, “The

Listener.”
[Contents]

23. The Story of the Ohohwa People

In a quiet forest, in a lodge of their own, a husband and his wife of

the Ohohwa people lived in much contention. It was their invariable
habit to quarrel all night long. In the morning, however, all was
pleasant again.

One night a visitor came to pay them a call. As soon as the man of
the lodge saw the newcomer he went away from the lodge.
Thereupon the would-be visitor remarked to the woman, “It is
indeed strange that he should go out just as I came in, so I shall go,
but will come again at another time.” With these words he left.

In a short time the husband returned, and being very jealous of his
wife, seized the occasion of this visit of a strange man to scold and
quarrel with her until, becoming enraged, he beat her and finally she
fought in defense of herself. At last, becoming tired of fighting, the
husband started off with the remark: “I am going to get another
wife. I will not be troubled in this way any longer.” Weeping bitterly,
she followed him until, touched by her plight, the husband grew
sorry for what he was doing and returned with her to their lodge.

In the morning he told his wife that he had had a dream during the
night. He said, “My dream spirit told me that I must kill a large bear
and be back home before the dew is off the grass.” Ostensibly
[145]he started away to carry out this injunction, but when he got out
of sight of the lodge he went to the lodge of another woman, who
also was of the Ohohwa people, where he remained all day. Toward
night he started for home. On his way he met a fine-looking woman.
He addressed her, saying, “Where are you going, my cousin?” She
replied, “Oh, I am only going home.” He asked, “Let me go home
with you?” Answering coquettishly, “All right, if you can overtake
me,” off she ran with great speed, with him in pursuit. This woman
was of the Djohkwehyanih 45 people.

All night long they ran toward the north. About midday they came to
a lodge, which the woman entered. The Ohohwa man followed, but
on entering the lodge he did not see the woman, but only two old
men. He asked them, “Have you seen a woman pass here?” The two
men sat with their heads down and did not answer the question. But
on the question being repeated by the intruder, one of the men,
looking up, said, “It seems to me that I heard some sound,” and the
other made the same remark. Then he who spoke first said, “Then
get our canoe.” Going to another part of the lodge, the second man
returned with a bark canoe and two basswood knives. “Now,” said
the other old man, “seize the game that has come to our lodge.” The
intruder drew back as the old man advanced, cautioning the old
men, saying: “Be very careful, old men. You are Nosgwais people, as
I know. I came only to ask for information.” But as the two old men
advanced the intruder turned and fled. The old men chased him with
great speed. After a while, turning and running back to the lodge, he
seized a wooden mallet and the first man that appeared at the
doorway he knocked on the head, and he did likewise to the second
man. As the old men picked themselves up they said, “It seems that
there is a great deal of fun in the game animal that has come to us.”
On their making another attempt to enter their lodge the intruder
again knocked them down. Thereupon one of the old men said: “Get
up and do the best you can [magically]. Are we to be beaten in this
way? It would indeed be a singular occurrence for us to be
overmatched by the game animal that has come to us.” But in
making a third attempt to enter the lodge the old men were still
again knocked down. But the intruder said to himself, however, “I
can not kill these people, and so I would better try to escape.” So,
passing out of the doorway at the opposite side of the lodge, he saw
the tracks of the woman going directly northward. He followed them
all day. When night came he still saw her tracks leading in the same
direction. He remarked to himself, “I will soon overtake her, I think.”
But these tracks were not those of the woman. He had made a
circuit and at daybreak he was near the starting point. He looked
down and, seeing his own [146]tracks, said: “Oh, another man is
following her! I will kill him when I overtake them.” Soon he came to
the lodge of the two old men from which he had started. Again he
inquired of the old men about the woman, but they caught him and
threw him into their canoe. Then they began to dispute as to which
should kill and quarter him. At last they said, “Push the canoe back
and leave it, for the game animal can not run away.” Indeed, the
man could not release himself, as he seemed to be fastened to the
canoe.

Toward night be heard a voice saying: “You think that you are going
to die. You would be were it not for me.” The man in the canoe
replied, “I do think so.” Then the invisible man said: “No; you shall
not die. At the end of the canoe there is a string, to which hang the
two hearts of the old men; and this is why you were not able to kill
them by knocking them on the head when you were here before (he
now knew for the first time that he was in the same lodge again).
Wait until it is dusk; then try to move and you will work loose. Then
get out of the canoe quietly, and I will give you light to see where
the hearts are. Take them off the string and pound them up, and
you will be free. You can then remain here all night. The canoe has
great orenda (magic power), and these two old men use the canoe
when they travel. If you wish, I will teach you the song that belongs
to it.” The man in the canoe, being very weak, could hardly speak,
but he replied, “Yes; I should like to learn the song.” Then the
invisible man answered, “I will teach you the song,” and he began
singing, “Tgâiiehe onĕⁿ o’waqdĕñdĭʼ neʼʹ akʻhoñwâⁿʼ.” When he
finished singing “Correctly my canoe has started” the man in the
canoe thanked him, saying that he had learned the song. After dusk
he began to move, and as he moved he gained strength. Looking
around, he saw a pale light in the end of the canoe. Having freed
himself, he took the hearts from the cord, and as he crushed them
he heard groans and wails of pain. Placing them under the canoe, he
crushed them, and their cries ceased. Then the young man lay down
and slept.

The next morning he awoke and said: “Now I have something in

which I can travel. I shall now soon overtake the woman.” Setting
the canoe outside of the lodge, he turned its bow toward the north,
and, getting into it, he sang the song which he had learned to cause
it to fly. The canoe started off so rapidly that only the wind could be
heard as it flowed past his ears. All the time the canoe kept going
higher and higher and swifter and swifter, and the youth grew more
and more frightened; he began to fear that the canoe might bear
him off to some evil place. Suddenly he heard a scrambling sound at
the stern of the canoe, as if some one were trying to board it from
the rear. Looking around, the youth saw a man getting aboard, who
said: “It is wonderful how fast you are going. I was bound to get
[147]aboard, so I leaped. You are afraid this canoe will carry you
away. I am the person who was with you last night. It is my fault
that you are frightened, for I did not give you full instructions. The
reason the canoe goes faster and faster and higher and higher is
that you keep repeating the song. You should change the words of
the song, and then you can guide it. I came to tell you this.” As he
stopped speaking, he stepped off the stern of the canoe into the air
and disappeared.
The youth now changed the words of the song, singing, “Tgāiiehe
wa’tkĕⁿ’dioñʹdă’t ne’ʹ akʻhoñʹwãⁿʼ,” and at once the canoe began to
descend, gradually coming to the ground. But the occupant of the
canoe exclaimed, “Oh! this is not what I wanted. I desired to come
down a little lower only, not to the ground.” So he sang again the
first words of the song. At once the canoe shot upward like an arrow
and, heading northward, flew faster than it did before. As it flew
along the youth saw the woman’s tracks ahead. Higher and higher
went the canoe, the wind whizzing past his ears in a frightful
manner. The speed of the canoe troubled the youth, and finally he
exclaimed, “Oh! I am getting too high again.” Then, recollecting that
he must change the words of the song, he sang, “Tgāiiehe
hehdageshon hohweson nakʻhoñʹwâⁿʼ.” The canoe descended, but
its speed was so great that he was greatly disturbed and distressed.
At last he said, “I have learned the music, and all I have to do is to
sing, ‘My canoe must stop immediately.’ ”

[The story ends here thus abruptly.]

[Contents]

24. The Chestnut Tree Guarded by the Seven Sisters

In a small lodge, deep in a dense forest, a man lived alone with his
nephew. It was the custom of the uncle to cook every day the food
required by his nephew, but he never ate with him. There came a
time, however, when the little nephew asked his uncle to eat with
him. The only reply was, “No; I have already eaten my food.” Then,
urging his nephew to be quiet, he would remark, “I have cooked this
food for you alone.”

As the little nephew grew older he began to wonder at this strange

conduct of his uncle. Finally he asked him: “Oh, my uncle, I never
see you eat! How is this?” But the uncle made him no reply. So the
little nephew decided to try to catch his uncle eating by spying on
him. One night after this, when the little nephew had eaten his
supper, he said: “Oh, uncle, I am very tired and sleepy. I am now
going to bed to get a good rest.” With this remark he lay down on
his bed, and drawing over him the deerskin cover soon began to
snore as if he were sound asleep. [148]

The wily old uncle waited a while, and then assuming that his
nephew was fast asleep, he decided to begin getting his own
evening meal. Going to his bed and carefully searching among the
skins with which it was covered, he drew forth a small kettle and a
very small bundle. Then placing the kettle on the bench near the fire
and opening the bundle, he took out of it some substance, a small
quantity of which he scraped into the kettle. After putting water into
the kettle he hung it over the fire. When the water began to boil the
old man, taking a wand from its wrappings of skin, began to strike
gently on the kettle while he sang the words, “Now, my kettle, I
want you to grow in size.” Obedient to the words of the song, the
kettle began to increase in size and its contents grew in bulk.
Repeating the words and continuing to tap gently on the kettle, the
old man watched it becoming larger and larger. He kept up the
singing until he decided that the kettle would hold enough of the
mush which he was making to satisfy his hunger; then he stopped
singing and tapping on the kettle. Carefully replacing the rod, or
wand, in its skin wrapping, he removed the kettle from the fire and
sat down to eat. After finishing his supper he carefully washed his
kettle; then he shook it until it decreased to the size it was when he
took it from the hiding place under the bed, to which place he now
returned the rod, the bundle, and the kettle.

The nephew, who was still feigning sleep, was watching his uncle
through a hole in the bed covering. He decided to take breakfast
with his uncle in the morning, and in order to do this he resolved to
arise much earlier than usual. When he arose, however, the youth
found that his uncle had finished breakfast and was preparing
something for him to eat.

After the uncle had gone out to hunt the youth brought into the
lodge a large quantity of bark to make a good fire. About midday he
said to himself: “I am going to be very kind and good. My uncle will
be tired when he returns, so I shall have his supper all ready for
him. I think that I can prepare it just as he does.” For a long time he
searched in his uncle’s bed for the bundle; at last he found it. On
opening it he discovered that it contained a small fragment of a
chestnut. Beside the bundle he found the kettle, which was very
small. These were the only articles he found under his uncle’s bed.
He wondered and wondered at what he had discovered, for he could
not understand how it was that with this bit of chestnut and the tiny
kettle his uncle could make enough mush to feed him. Finally he
decided on his course of action, saying to himself: “Well, I must do
this exactly as my uncle did. This chestnut must be enough for one
more meal.”

Kindling a good fire, the youth carefully scraped all the chestnut into
the kettle; and then he poured water into the kettle and set it
[149]over the fire. Then taking the wand from its skin wrapping,
when the water began to boil he gently tapped on the kettle, saying,
“I want you to grow, my kettle.” He was so much amused by the
increase in size of the kettle that he kept on tapping it and repeating
the magical words, until there was hardly room enough in the lodge
for him, because the kettle and the mush which it contained had
grown so large; so, climbing to the roof, he continued to tap the
kettle until it touched the sides of the lodge. He was so busy that he
did not see his uncle approaching. The latter from a distance saw
him on the roof, and watched his actions. As he approached the
lodge he heard the nephew say, “Oh, grow! my kettle. Oh, grow! my
little kettle,” and then he knew that the youth had discovered
everything. This made the uncle very sad and depressed. He called
to his nephew: “What have you done now, my nephew?” The youth
replied in delight: “Oh, I have so much pudding that we shall have a
grand feast.” Then he told his uncle everything.

The uncle asked, “Did you use all the chestnut?” The youth replied,
“Yes. There was only a small bit here.” Thereupon the poor uncle
exclaimed: “By doing this you kill me. That is the only kind of food I
can eat. I shall die of hunger now. That kind of chestnut does not
grow everywhere, and only a person who has great orenda (magic
power) can get it.” “Oh, pshaw!” replied the nephew; “I know where
there are whole trees full of chestnuts of this kind. I can get a large
bagful for you, my uncle. So do not worry.” The uncle, unconsoled,
replied: “No, it is not possible for you to do so. This is a bad thing
that you have done. This chestnut would have lasted me for years.
Now I never can get another; I shall starve to death. I may as well
tell you about it, for I must soon die.”

Then, shaking the kettle slightly to decrease its size so that he could
get into the lodge, the uncle said: “There is but one tree in the world
that bears such chestnuts. Seven sisters who are great sorcerers
own that tree. Many men have lost their lives in trying to get these
chestnuts.” The youth confidently replied, “I am sure that I can get
you one.” The uncle answered: “No, you can not. You are yet only a
small boy. You would lose your life. These seven women have a
great eagle perched upon a very tall tree to watch it. Night and day
he guards it. Not a living thing can come near the tree, for if even a
man try his utmost the eagle would discover him and scream out a
cry of distress. Thereupon the sisters would come forth and beat the
intruder to death no matter who he might be. Men have often taken
the forms of various birds and animals to try to deceive them, but so
far they have all failed in their attempts. These seven sisters have
beaten to death everything that has come near that chestnut tree.”
But this kindly advice did not change the youth’s resolve to make the
attempt to get some of these well-guarded chestnuts. [150]

The next morning he said to his uncle, “You must tell me where the
tree stands, for I am going to try to find it.” When the fond uncle
saw that he could not repress his nephew’s desire to go, he replied:
“Go toward the rising sun, and after you have passed through the
forests intervening you will come to a large open space. In the
middle of this great clearing you will see a very tall tree near which
stands a lodge. On the top of this tree sits the eagle with his sharp
eyes looking in all directions; and it is in this lodge that the seven
sisters dwell.”

Taking a bag, the young nephew said: “Now, cheer up, uncle. I will
bring you a whole bagful of chestnuts before you have finished
eating the pudding in that kettle.” With this remark the youth started
toward the sunrise. After traveling for some time he killed a deer,
which he cut up, filling his bag with the venison.

Finally the nephew came to a place where he began to see through

the forests to an opening, whereupon he resolved that he must put
forth all his caution and craft. So, having the mole as his fetish, he
called out “Now, my friend, I want you to come to me; come to me,
you mole!” In a short time the leaves began to rustle at his feet, and
a mother mole appeared and asked him, “What do you want of me?”
The youth replied: “I have done a great mischief to my uncle by
scraping away all his chestnut. Now I want you to help me get more
for him. I shall enter your body and you will carry me underground
to that tall tree yonder on which the eagle is sitting. When you are
under the tree thrust out your nose a little so that I can see. I shall
have to carry my bag with me. Do you think that you can bear me
and it, too?” The mole answered, “Oh, yes! I can carry all.”

After reducing his size magically, the youth entered the body of the
mole and then it made its way to the tree indicated. As the mole
arrived directly under the tree, thrusting its nose out of the ground,
it said, “The eagle is looking.” In a flash the youth, stepping out of
the mole, scattered venison all over the ground under the tree. The
eagle flew down and began to eat voraciously of the meat. In the
meantime the youth stuffed his bag with the chestnuts, which he
gathered in handfuls, and just as the eagle was finishing the last
morsel, the mole was engaged in carrying the youth with his bag
back to the forest. When the meat was all eaten the eagle uttered a
loud scream, and out ran the seven sisters with their clubs. When
they saw that the chestnuts were already stolen and that no one
was in sight, they fell upon the eagle and beat it until they had
nearly killed him.

Arriving in the forest, the youth said to the mole: “Now, I will hide
my chestnuts here, and you must then take me back to the lodge of
the seven sisters, so I can hear what they say, in order to [151]learn
whether they intend to follow us in an attempt to recover the
chestnuts.” Having again entered the body of the mole, the youth
told it to go under the ground until it came to the lodge. The mole
obeyed him literally. When the mole reached the lodge, it thrust out
its nose and mouth. The youth then stuck his ear out of its mouth
and listened to what was being said in the lodge. He finally
overheard one of the sisters say: “It must be a young man just
grown. No one has succeeded since his uncle in stealing the
chestnuts. Perhaps he has a nephew now who is as crafty as he
used to be, and it may be that he, too, is going to live on chestnuts.”
Another answered her, saying: “Well, they are stolen. We may as
well let them go.” After hearing this last speech the youth asked the
mole to bear him back to the forest at once. After reaching the
forest the youth dismissed the mole with thanks for its aid, and then
hurried home.

When the youth reached home he found his uncle sitting by the fire,
singing his death song, “I must now die of hunger, for my nephew
will never return to me.” Then the nephew rushed into the lodge,
saying, “Oh, my uncle! I have brought you here a bag full of
chestnuts.” The old man welcomed his nephew home and gave
thanks to their guardian spirits for the latter’s success, and he was
very, very happy. He is still making chestnut puddings. His nephew
became a great hunter. He obtained whatever be desired, because
he had the mole for his guardian spirit and aid.
[Note.—There are several versions of the foregoing story. In one
version the tree is guarded by geese. The lad entered one of the
geese, and as the seven sisters were bathing he slipped from the
goose into the person of the youngest sister, and she thereby
became pregnant. Being born of her, he became the master of the
chestnuts.]
[Contents]

25. The Otter’s Heart and the Claw Fetishes

Once in the fall of the year in time long past, a prominent chief with
six or seven families went on a hunting expedition far away from
their village. Having arrived at their usual hunting grounds, they did
not find any game for many days. At last the chief, whose fetish, or
charm, was a fawn skin, calling the members of the party to his
kanosʻha (temporary lodge), asked each person to lay hold of his
pouch fetish, and to declare while touching the pouch what he or
she intended to kill on the following day.

The first one to touch the pouch was a man who said that he
intended to kill a bear; the next said that he intended to kill a deer,
and so on; and finally the chief’s wife declared that she intended to
kill geese. But, as the pouch passed around, the chief’s daughter
requested her husband not to touch it by any means; when it was
nearing [152]them on its round she grasped her husband’s arm to
keep him the more effectually from putting his hand on the pouch.
As he showed a disposition to touch it, she pushed him over on the
ground, but he arose again while she still clung to him. In spite of
her he finally placed his hand on the pouch, saying, “Tomorrow, I
shall kill two otters before daylight.”

At midnight the chief’s son-in-law, arising, went to a place where the

neighboring stream made a very pronounced loop, and there he
watched for the otters. Soon he saw two approaching and killed
both. He was very hungry, and as it was not yet daylight he took out
the hearts of the otters, which he roasted and ate. By doing this he
unwittingly destroyed the power of the orenda (magic potency) of
the pouch for those who had touched it; so that day all the other
persons returned to the lodge without any game. The chief’s wife,
who had said that she would kill geese, also returned empty handed.
When she saw the geese on the wing and clapped her hands,
shouting: “Let them fall dead! Let them fall dead!” the geese kept on
flying; in fact the charm, or orenda, of the pouch had been broken
or spoiled by some one. After these things had been reported to the
chief, he examined the two otters slain by his son-in-law. When he
saw that their hearts had been removed, he became very angry with
him. His daughter, the wife of the culprit, becoming frightened for
the welfare of her husband, concealed a piece of dog’s flesh and a
knife, at the same time telling her husband where he could find
them in case of need.

The chief said to his retinue, “My son-in-law has nullified the orenda
of the pouch by eating one of the taboos, which is the earnest of the
compact with it; so I think we would better kill him.” But his
daughter exclaimed, “If you kill him, you must first kill me.” As the
chief was quite averse to killing his daughter, he said, “Then, instead
of killing him we will leave him here naked and without provisions
and we will go far away to avoid the consequences of his act.” So
the chief and the people stripped the son-in-law of everything, even
of his weapons, and then departed, taking his wife with them.

At midnight, when all alone, the son-in-law heard some person

approaching on snowshoes, for this was in the winter season. In a
short time a man came to the lodge and said to the young man,
“You feel that you are doomed to die, do you not?” The young man
answered, “Yes; I do think so.” Then the stranger said: “You shall
not die. I have come here to assist you. Tomorrow morning follow
my tracks to a hollow tree. There you shall find a bear. Kill it and you
will have plenty of meat and you can make yourself a robe and
footwear from its skin.” Then the stranger went away. The next
morning the young man could find no tracks other than [153]those of
a rabbit. These he followed to a large hollow tree, in which indeed
he found a bear, which he killed. Carrying it home, he skinned and
dressed it. From its skin he made himself a robe and a pair of
moccasins.

Again about midnight the young man heard some person

approaching on snowshoes, for the snow was deep. Soon a man’s
voice from outside his lodge said to him: “I sent you help last night.
Tonight I have come to tell you that your wife will be here tomorrow
about midday. She believes that you are dead from hunger and
exposure and she has run away from her father’s camp to come to
look for you. As soon as she has rested, send her on the following
day for her father and his people. Instruct her to tell her father that
you are alive and well. Let her say to him, ‘My husband has meat
enough for all.’ They will be glad to come back to you, for they have
no meat and are hungry. They have been punished enough for
abandoning you.” Then the stranger departed.

The next day about noontide the wife came and she was welcomed
by her husband. After resting that night the young man in the
morning sent her for her father. The night she was absent the
stranger again came to the lodge and said to the young man: “Your
father-in-law will be very glad to know that you have meat sufficient
for yourself and for his people, and he will be very willing to come to
you. When he has arrived here he will exhibit his fetishes, and
ostensibly to repay you he will give you your choice. Among them is
one which you must select; this is wrapped in bearskin. It is the claw
which I lost when your father-in-law caught me in a trap. You must
not pay heed to your father-in-law’s statement that it is not of much
account. He will insist that you take some other which he will
represent as of much greater potency than this. But take my advice
and choose this one.” Then the stranger departed.

The next morning toward midday the chief and all his people
returned to the lodge of the chief’s son-in-law, who welcomed them
and offered them what he had in the way of food.

In a few days the chief unfolded all his fetishes, informing his son-in-
law that he could take his choice. On his reaching over and taking
the one wrapped in bearskin, his father-in-law said, “Oh, son-in-law!
that is of no account; here is a better one.” But the young man,
remembering the advice of his midnight visitor, replied, “No; I will
keep this one,” so he retained the one wrapped in bearskin.

Some time afterward the young man went into the forest to meet
the strange man who had befriended him and to whom the claw, or
finger, belonged. He had not gone far when he saw what appeared
to be a lodge standing in the middle of a clearing. On going to this
lodge he found a man in it who received from him the claw or finger.
Thanking him for its return, the man said: “I shall always [154]be
your friend for this favor. You shall succeed in all that you may
undertake.” As the young man turned to go home the strange man
bade him farewell. Having proceeded a short distance toward home,
the young man turned to take a look at the lodge, but to his surprise
it had disappeared. What he had thought was an opening in the
forest was now a large body of water.

Ever after this circumstance the chief’s son-in-law enjoyed good

fortune in all that he undertook. He became a great hunter and a
great warrior. When his tribe waged a war against a neighboring
people he took many scalps and many prisoners. Whatever he
desired he obtained easily in abundance. It was said by those who
knew the circumstances that his good luck came from the friendship
of the otter, whose finger, or claw, the young man had so generously
returned to it.
[Contents]

26. The Seven Sisters Who Produced Wampum

In the long ago there lived seven sisters who were endowed through
their orenda with great skill in sorcery. These sisters lived together in
a lodge situated on a high mountain. From this advantageous
situation they were able to see a long distance in every direction.

One of their chief occupations during berrying time was to gather

large quantities of huckleberries for drying and storing. They would
carry long baskets on their backs by means of the forehead strap
and smaller ones in their hands, for collecting the berries from the
plants and bushes. These berries they gathered in the neighboring
patches which belonged to them and brought them home to dry in
the sun.

Now, it so happened that these seven sisters were misanthropes,

and they boasted that they hated men. Each one of them sincerely
and frequently said, “I can not bear the odor of a man.” True to their
animosity to men, they would not permit one to come near their
domicile. They carried this aversion to the presence of men to the
extent that they would have no relations whatever with married
women, even turning up their noses at them, with the contemptuous
remark, “Oh, they smell of men.” So they would not allow either men
or women near their huckleberry patch.
Among the young men who heard of these peculiar sisters was one
who determined to have a look at them. In order to see them he
managed to conceal himself in their huckleberry patch about the
time of their coming. When the sisters, therefore, came with their
baskets into the berry patch the young man saw the youngest, with
whom he immediately fell deeply in love, for she was very beautiful
in face and attractive in figure. He then and there decided to
approach [155]stealthily the spot where she was picking berries by
herself and to speak to her at all hazards. He did not get the
opportunity until the next day.

On going again to the spot he had chosen as the best place to meet
her, he concealed himself and awaited the coming of the seven
sisters to their daily task of gathering berries. By good fortune the
youngest sister came directly to the place near which the ardent
gallant was concealed, and he lost little time in making his presence
known by speaking to her in very low tones lest the other sisters
should hear him. The sister addressed, turning around, saw him and
at once fell in love with him, for he was a fine-looking young man.
He said to her, “I greatly desire to speak to you, but I do not want
your sisters to overhear me, for I am afraid of them.” So she
stopped picking berries and listened to what he had to say to her.
They conversed together for a long time. At last he remarked: “I
must go lest your sisters discover me. I will meet you here
tomorrow.”

After her lover had gone the youngest sister tried very diligently to
fill her basket with huckleberries, but she did not have time to do so
before the eldest sister called out, “Come, now, my sisters, our
baskets are full, and we must go home.” They started toward their
lodge, but missing their youngest sister, called her until she came.
She acted shyly, being afraid to go very near them lest they should
detect any odor which would let them know that she had been near
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookgate.com