Wordware publishing memory management algorithms and implementation in c and c++

Memory Management: Algorithms and Implementation in C/C++ ISBN:1556223471 by Bill Blunden Wordware Publishing © 2003 (360 pages) This book presents several concrete implementations of garbage collection and explicit memory management algorithms Table of Contents Memory Management—Algorithms and Implementation in C/C++ Introduction Memory Management Chapter 1 Mechanisms Memory Management Chapter 2 Policies Chapter 3 - High-Level Services Manual Memory Chapter 4 Management Automatic Memory Chapter 5 Management Chapter 6 - Miscellaneous Topics Index List of Figures List of Tables List of Case Studies List of Sidebars 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 Memory management (Computer science) 2 Computer algorithms C (Computer program language) 4 C++ (Computer program language) I Title QA76.9.M45 B558 2002 005.4'35 dc21 2002012447 CIP Copyright © 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" 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 believing 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 various 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 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 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 triplefault club After obtaining a BA in mathematical 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 Silicon Valley Currently on the peninsula, Bill survives rolling power blackouts and earthquakes, and is slowly recovering from his initial bout with COBOL Introduction "Pay no attention to the man behind the curtain." —The Wizard of Oz There are a multitude of academic computer science texts that discuss 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 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 subsystems 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 example, 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 Colossus: 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 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 example, 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 Chemical 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 correct Before the dawn of calculators, errors were more common, 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 computations 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 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 vacation 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 Principle, shown below, is what prevents us from building infinitely small components ΔxΔ p ≥ (h/4π) 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 precisely 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 .. .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... Memory management: algorithms and implementation in C/ C++ / by Bill Blunden p cm Includes bibliographical references and index ISBN 1-55622-347-1 Memory management (Computer science) 2 Computer algorithms C (Computer program language) 4... subspecies of tracing garbage collectors, including mark-sweep, markcompact, and copying garbage collectors An outline of different automatic memory management approaches is provided in Figure 5.1 Figure 5.1 In this chapter I am going to examine a couple of garbage collection